On Jan 16, 2008 10:16 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
Alex Karasulu wrote:
> Hi all,
> On Jan 16, 2008 5:26 AM, Emmanuel Lecharny <elecharny@gmail.com
> <mailto: elecharny@gmail.com>> 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?
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.