[Date Prev][Date Next]
Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails
--On Friday, November 14, 2008 9:34 PM +0000 firstname.lastname@example.org wrote:
> email@example.com wrote:
>> firstname.lastname@example.org wrote:
>>> Pierangelo Masarati writes:
>>>> I think ITS#5326 is related. Namely, write operations (add, rename)
>>>> should always rebuild the (new)DN hierarchically from the tree.
>>> I'm not sure what exactly the problem is, if any:-) Syncrepl itself
>>> needs to handle databases that are not that nice: We can't require
>>> that of back-perl, nor back-ldap which accesses a non-OpenLDAP server
>>> (if that makes any sense). And syncrepl + rwm, maybe? Also syncrepl
>>> is an RFC (4533) so it should handle non-OpenLDAP peers.
>> Syncrepl of course *handles* all of those cases. The only issue here is
>> that our tests expect the results to be in a specific order, which is
>> obviously an invalid requirement in the grand scheme of things.
> I'm hitting an issue like this in some of the replication tests I'm
> currently performing. For this purpose, I think we could hack
> ldapsearch (or add a new prog, or use a script on ldapsearch output)
> that sorts entries content attribute-wise and, within each attribute,
> value-wise. Something like "sort" applied entry-wise after unwrapping
> line folding, optionally case-insensitive would probably suffice.
I have a script somewhere from Matt Backes @ Symas that sorts LDIF files.
It was useful for seeing if it made any difference in slapadd (it didn't).
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration