[Date Prev][Date Next]
Re: Thinking about operational attribute numSubordinates...
> In implementing this, there are two basic approaches.
> a) maintain the attribute as part of the entry;
> b) compute the attribute when requested.
> I favor b. Namely because a) would be a pain to maintain.
> I would suggest that implementation do the following:
> On search into a backend supporting the attribute,
> determine if the attribute is requested. If requested,
> compute value on a per entry basis by examining the
> oneLevel index associated with that entry. Pass this
> information to the front end so that the attribute
> can be generated.
> The question to be answered is how to pass the information
> about. A hack would be to put a varible in the op structure
> which was 0 (not present) or 1 (false) or 2 (true) (set by
> the and have backend_operational() generate the attribute
> needed. A better approach would be to think out how such
> information, in general, should be passed about.
I note (after playing with a gross implementation of the
hasSubordinates) that the operational attributes generated
on the fly (like hasSubordinates and subschemaSubentry
itself) cannot be used in filters; extra hacking is required.
I'll think about a way to have these attributes available
whenever required in a reasonably efficient way; I think
we first need to decide whether this requirement is a MUST
or we can live without.