Re: (ITS#5809) syncrepl + back-ldif + "rename to same DN" fails

[hyc@symas.com]

Pierangelo Masarati wrote:
> hyc@symas.com wrote:
>> h.b.furuseth@usit.uio.no 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.

Hm, I already added that, when I was first putting back-ndb thru the test 
suite. In acfilter.sh, but currently only used for back-ndb too.

At any rate, I've tweaked the consumer's rename detection code, so this 
specific ITS is now fixed.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/