But in "real-life", usually, entry types are typically broken into containers on at least a broad basis like:
ou=People, dc=willeke,dc=com ou=groups, dc=willeke,dc=com So we provide the counter people with a search filter like: (Vendor specific to eDirectory) (objectClass=ndsContainerLoginProperties) and return subordinateCount The search is extremely quick and provides the counts they require. No, not precise, but practical, especially as there are 25+Million entries. ᐧ -- -jim Jim Willeke On Thu, Dec 11, 2014 at 8:17 AM, Emmanuel Lécharny <[email protected]> wrote: > Le 11/12/14 13:21, Michael Ströder a écrit : > > Jim Willeke wrote: > >> There is an old draft for: > >> https://tools.ietf.org/html/draft-ietf-boreham-numsubordinates-01 > >> > >> And I do think this type of attribute does supply value. Many client we > >> work with monitor container counts for stats and compliance. > > Not many servers support numSubordinates though. And it's of less value > when > > search scope and search filter come into play. > > The fact is that ApacheDS *does* support numSubordinates. We keep a > track of the numbe rof direct children and the track of descendant for > every entry. > > It might be seen as costly, but it's not : as we have to update the full > RDN index when we add/remover/move an entry, we just have two counters > to increment in each RDN, which is just insignificant compared to the > cost of writing those RDN on disk. > > Now, it's just counting entries in the DIT, it's not really helpful when > we have to evaluate the number of entries a search will return. > > This is where it starts to be complicated, because you really have to > filter each entry to see if it matches (and also to check that the ACLs > don't forbid the entry to be returned to the client). > > All in all, counting the number of elements based on any filter/search > *will* be a costly operation, you still have to pull the entries from > teh backend. >
