directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [ApacheDS] Partition design and interfaces
Date Wed, 16 Jan 2008 16:55:06 GMT
On Jan 16, 2008 10:16 AM, Emmanuel Lecharny <> wrote:

> Alex Karasulu wrote:
> > Hi all,
> >
> > On Jan 16, 2008 5:26 AM, Emmanuel Lecharny <
> > <>> wrote:
> >
> >     Hi Alex, PAM,
> >
> >     if we are to go away from JNDI, Option 2 is out of question.
> >     Anyway, the
> >     backend role is to store data, which has nothing in common with
> >     Naming,
> >     isn't it ?
> >
> >
> > Well if you mean the tables yes you're right it has little to do with
> > javax.naming except for one little thing that keeps pissing me off
> > which is the fact that normalization is needed by indices to function
> > properly.  And normalizers generate NamingExceptions.  If anyone has
> > any idea on how best to deal with this please let me know.
> Well, indices should have been normalized *before* being stored,

That's exactly the case.  What is stored in an index is always normalized.
I think what you mean is someone should provide the index with the
normalized value so the index does not have to hold an normalizer and ask
that normalizer to do the work of normalizing right?

> and
> this is what we are working on with the new ServerEntry/Attribute/Value
> stuff, so your problem will vanish soon ;) (well, not _that_ soon, but
> ...)

Yep and you're doing a great job Emmanuel!  I cannot wait to switch over to
it in these lower layers.  I'm almost there in my private branch.  Do you
think I should switch over to ServerEntry now before I make the search code
use a Cursor instead of the NamingEnumeration it uses now?

I guess I should hmmm.  It's going to be less a refactoring then since all
will change and for the better.  It's just a bigbang ;).

> Note the BTree Partition Layer is where we have interfaces defined
> > like Table, and Index.  These structures along with Cursors are to be
> > used by this default search engine to conduct search.  We can then
> > swap out btree implementations between in memory, JE and JDBM easily
> > without messing with the search algorithm.
> This is where things get tricky... But as soon as we can clearly define
> the different layers without having some kind of overlap, then we will
> be done. The pb with our current impl is that we are mixing the search
> engine with the way data are stored. Your 'cursor' implementation will
> help a lot solving this problem.

I'm hoping.  All this work is resting on a heck of a lot of theory but then
again ApacheDS has all been about theory up until this point. Asking if it
can be done is just a waste of time now.


View raw message