On 8/16/11 3:22 PM, Kiran Ayyagari wrote:
> On Tue, Aug 16, 2011 at 6:45 PM, Stefan Seelmann<seelmann@apache.org>  wrote:
>> On Tue, Aug 16, 2011 at 2:22 PM, Kiran Ayyagari<kayyagari@apache.org>  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