[Date Prev][Date Next]
Re: (ITS#6072) slapo-collect: dnLength != dnDepth
Hallvard B Furuseth wrote:
>> DNs should be ordered accoring their in-DIT depth and not accoring their
> 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
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:
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. ;-)