On 8/16/11 3:22 PM, Kiran Ayyagari wrote:
On Tue, Aug 16, 2011 at 6:45 PM, Stefan Seelmann<[email protected]> wrote:
On Tue, Aug 16, 2011 at 2:22 PM, Kiran Ayyagari<[email protected]> wrote:
One solution would be to store two more elements in the ParentIdAndRdn data
structure : the number of children directly below the RDN, and the number of
children and descendant. That would probably solve the issue I'm mentioning.
Of course, that also means we wil have to update all the RDN hierarchy from
top to bottom (but affecting only the RDN part of the entry DN) each time we
add/move/delete an entry. Note that we already do that for the oneLevel and
Sublevel index.
Just to make a point:
I think, in the case of achieving SubLevel index evaluation with RDN
index it becomes a costly and complex operation
(recursive scanning and updating) where as with the current sublevel
index it takes O(1) to fetch all the sublevel children of
an entry.
Hm, evalutation can easly be done by using the reverse RDN index table.
for one level it is straight forward, but for sublevel we still need
to use recursion, no?
No, if we update all the parents when we add/move/delete an entry. That
means we have to update more than one RdnAndparent element (in fact, as
many as we have RDns but the namingContext in the DN). Nothing more
though that what we already do in the sub-level context.
Then we have a O(1) operation to get the number of children in the case
of a SUB search.
Now, Stefan is right, fetching entries means we use more than one cursor
for that.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
