Hi Emmanuel, On Wed, Feb 23, 2011 at 11:14 AM, Emmanuel Lecharny <[email protected]> wrote: > Hi guys, > > those last 2 days I did some cleanup in the Rdn and Ava classes, in th > espirit of Dn cleanup. Here is a summary of what has been done, roughly : > > - injection of the SchemaManager in both classes' constructors > - removing of the compareTo method > - made some methods private > - made the classes final > - removed the Comparable interface from the equation
Thanks for that. > One important modification is the last one : it makes no sense to have a Rdn > be comparable. First, how do we compare a cn and a jpegPhoto ? Second, how > do we compare two RDN which attributeType does not have an equality matching > rule ? > > Of course, this has an impact in the way the backend works, as the Rdn index > needs to be able to do ordered comparison between Rdn, as this index is a > BTree. What I did is that I replaced the Rdn.compareTo(Rdn) method by a > direct String comparison in Jdbm between the Rdn's normalized name. That > does work. That's ok. > It made me think that maybe using a hashed index for Rdn is probably a > better idea, because then we won't need this comparison to be done (the > equals method would be enough) and also because it would be faster (finding > an element in a Hash table is an O(1) operation - at least, theorically - > when looking in a BTree is an O(log2(N))) I think in the current state the RDN index doesn't need to be ordered data structure, a hash table is sufficient. However we still need to cleanup the backends. One idea I had is to get rid of the onlevel and sublevel index and use the RDN index instead. I did that in the HBase prototype where the onelevel and sublevel index are no physical indexes but backed by the RDN index table. But if we do that then I think the RDN index needs to be a ordered data structure to be able to traverse the index using a cursor. Kind Regards, Stefan
