directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Rdn and Ava cleanup
Date Thu, 24 Feb 2011 01:50:16 GMT
On Wed, Feb 23, 2011 at 8:51 PM, Stefan Seelmann <> wrote:
> Hi Emmanuel,
> On Wed, Feb 23, 2011 at 11:14 AM, Emmanuel Lecharny <> 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.

Yes we need an ordered index and hence we need to be able to compare
two RDN values to sort.

I never considered making the onelevel and sublevel indices backed by
the RDN index. It makes sense to do this and would improve performance
because there's less house keeping to do and less IO on separate



View raw message