On Jan 16, 2008 10:16 AM, Emmanuel Lecharny <email@example.com> wrote:
Alex Karasulu wrote:
> Hi all,
> On Jan 16, 2008 5:26 AM, Emmanuel Lecharny <firstname.lastname@example.org> <mailto: email@example.com>> wrote:Well, indices should have been normalized *before* being stored,
> 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
> 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.
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 ...)
> Note the BTree Partition Layer is where we have interfaces definedThis is where things get tricky... But as soon as we can clearly define
> 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.
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.