Re: (ITS#6072) slapo-collect: dnLength != dnDepth

[daniel@pluta.biz]

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. ;-)