directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <>
Subject Re: HBase partition integration in trunks ?
Date Tue, 16 Aug 2011 13:49:25 GMT
On Tue, Aug 16, 2011 at 7:06 PM, Emmanuel Lecharny <> wrote:
> On 8/16/11 3:22 PM, Kiran Ayyagari wrote:
>> On Tue, Aug 16, 2011 at 6:45 PM, Stefan Seelmann<>
>>  wrote:
>>> On Tue, Aug 16, 2011 at 2:22 PM, Kiran Ayyagari<>
>>>  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.
if we are only talking about 'number of children' then this holds
good, but not when it comes to getting the
sublevel child entry ids, in case of existing sublevel index we get
*all* the child ids in one lookup
> Now, Stefan is right, fetching entries means we use more than one cursor for
> that.
yeap, the above step is where this many cursors will be opened to
collect the entry ids
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny

Kiran Ayyagari

View raw message