Hallvard B Furuseth wrote:
DNs should be ordered accoring their in-DIT depth and not accoring their bv_len:
Does that matter, as long as (child, parent) are ordered correctly? What is the bug you are fixing?
it's regarding the mentioned "*limited* overlapping feature" within the insert_ordered()-function's comment:
cite: "... this means longer dn's (i.e. more specific dn's) will be found first when searching..."
But, longer DNs do not neccessarily are more specific:
ou=openldap,o=rockz,c=it dc=abcdefghijklmnopqrstuvwxyz,dc=com (even longer but not more specific)
BTW: the use of insert_ordered() possibly cause some kind of strange (randomized) deletion of a collect_info config attribute's value in this overlay just in the case: c->type == LDAP_MOD_DELETE combined with c->valx > 1
I've noticed this behaviour during testing of my own (chaotic-)test-overlay but had no time to investigate in deep. In my opinion the effect depends on the order of ldapadds of additional DNs and the effective resulting order produced by insert_ordered in combination with "c->valx"... I would file another ITS in case I'm sure that this impressive effect is not cause by my "chaotic" component. ;-)