Hi Stefan, Working on JDBM, I was wondering what kind of cosistency gurantees does HBASE partition implemenation expose? In particular, do put and fetch operations on the underlying master table and indices have ACID properties? How about cursors? Do cursors see future changes as they move back and forth?
regards, Selcuk On Tue, Aug 16, 2011 at 4:49 PM, Kiran Ayyagari <[email protected]> wrote: > On Tue, Aug 16, 2011 at 7:06 PM, Emmanuel Lecharny <[email protected]> > wrote: >> 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. >> > 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 >> www.iktek.com >> >> > > > > -- > Kiran Ayyagari >
