directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: nbSubordnates, nbChildren, was: Work in progress...
Date Mon, 07 Mar 2016 23:26:01 GMT
Le 07/03/16 21:29, Howard Chu a écrit :
> Emmanuel Lécharny wrote:
>> Le 07/03/16 20:45, Stefan Seelmann a écrit :
>>> On 03/06/2016 02:49 AM, Emmanuel Lécharny wrote:
>>>> I think it will be very useful for studio, when running against
>>>> ApacheDS, as once can now expose the number of *real* childrens and
>>>> subrdinates without having to fetch them from teh server (more
>>>> important, we won't be limited by the SizeLimit that can be set -
>>>> typically 1000).
>>>> I wish we can have the same feature added to OpenLDAP and the other
>>>> servers...
>>> Well some servers support something similar: Novell has a
>>> "subordinateCount" AT, SunDS/OpenDS/OpenDJ have a "numSubordinates" and
>>> "hasSubordinates" AT. numSubordinates is defined in an expired draft
>>> [1]
>>> and has OID assigned. hasSubordinates is even
>>> defined in X.501 and has official OID assigned.
>> I took the idea from SunDS, leveraging the fact that we have the
>> information available.
>>> In Studio we use those attributes but only to indicate if an entry
>>> contains children or not and ot make the item in the tree expandable
>>> or not.
>> Good
>>> Maybe we can add at lease hasSubordinates additionally, then other LDAP
>>> clients that already support it can leverage it.
>> I can add the hasSubordinates AT easily.
>>> I think numSubordinates and subordinateCount only mean the number of
>>> direct children, whereas our nbSubordinates means all.
>> Because we have the nbChildren that gives the direct number of children.
>>> I think in Studio we can add support for those, we can extend the
>>> number
>>> shown for an entry like that:
>>>      ou=users (1000/23456/456789)
>>> which means 1000 entries fetched, out of 23456 direct children out of
>>> 456789 total subordinates.
>> Sounds like a good idea, although it's a bit heavy. How about having
>> just the number of children as a default, and a hover to give the number
>> of fetched and subordinates ?
>> Most of the time, people won't fetch the entries.
> OpenLDAP has supported hasSubordinates for quite a long time. The
> current back-mdb has the necessary info to provide numSubordinates but
> we didn't see a need to implement it. 

Same here, but in Studio, the need is obvious : when you expose a set of
entries, you have no clue about those having children, and no clue about
how many of them (actually, as Stefan says, it depends on the diretcory
server Studio is talking to). So the only way is actually to read the
entry's children to have this count.

The hasSubordinates is clearly good to have, as it allows Studio to at
last inform the user that there are some entries below.

ApacheDS had none of hasSubordinates/nbChildren/nbSubordinates exposed,
leaving us in a position where studio was offering a better user
experience with any other LDAP server :/

Now, assuming you don't have the number of subordinates (or children)
available, you won't get it by fetching teh entry's children because you
may reach the server's limit. Using a PagedSearch to browse all the
children would not only be a tehcnical non-sense, but will also only
work if teh remote server supports such a control. Bottom line, haing at
least the number of children returned within each entry offers us some

There is also one frequent need from LDAP users : "give us the number of
children, so that we can manage the presentation properly".

> back-bdb/hdb don't have the info for numSubordinates and since they
> are deprecated, we would not be adding anything to them any more.
> (Actually, I don't know which you're referring to. They could all
> provide the number of immediate children; the total number of
> subordinates in the subtree is only directly available in back-mdb at
> the moment.)
I do think that the number of direct children is really the important
information. The number of subordinates (ie children and all the
descendant) is quite cosmetic. It's more about being able to knwo how
much entries your database has when fetching the context entry. We have
this information in ApacheDS, it was easy to provide it at the same time
we provided the nbChildren.

Last, not least : the cost of providing this information is not null. We
have to do a fetch on the Rdn index for every entry, which adds an extra
cost of 10% the time it takes to grab the same entry without this
attribute. We could have cached this information, or grab it while
constructing the DN, but that would have meant a way more complex
refactoring and a complicated entry/DN cache management... Not worths
the effort, IMHO.

View raw message