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.