[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Thinking about operational attribute numSubordinates...

> Pierangelo Masarati wrote:
> > 
> > You may try it out.  I just committed a very rough implementation
> > for back-ldbm and back-monitor.
> It seems to work correctly.
> BTW: I noticed that slapadd does not parse base64-encoded DNs with
> UTF-8 chars. This works in REL_ENG_2 branch.

Se Stig's message ...
> >  I note that while (at least for
> > back-ldbm) the presence of at least a child SHOULD be consistent
> > with the value of the attribute, for back-monitor, due to the
> > existence of dynamic entries, I made it assume the TRUE value if
> > children are present __OR__ if the entry allows dynamic children.
> For your records: In web2ldap I have two situation where I honor
> hasSubordinates and numSubordinates attributes if present.
> Displaying search results. The [Down] link is only displayed if both
> attributes are absent or (hasAttribute is FALSE and numSubordinates
> > 0) => it tends to assume that an entry is a non-leaf entry and displays the [Down] link.
> Recursive deletes: I assume that an entry is a leaf which can be
> deleted if both attributes are absent or hasAttribute is TRUE or
> numSubordinates==0 => it tends to assume that an entry is a leaf
> entry and will try to delete it.
> It seems to work fine with Netscape Directory Server, OpenLDAP HEAD
> with the hasSubordinates hack and some X.500 servers out there.

Fine.  See Kurt's message about numSubordinates; I'd prefer to
take advantage of the lack of a standard track to avoid the difficulties
of implementing that. In case, to optimize reads it could be better
maintained in the database, because, due to the implementation, 
computing it could be non-trivial.