directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [ApacheDS] Partition design and interfaces
Date Wed, 16 Jan 2008 15:16:26 GMT
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, 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 ...)
>  
>
>     and I
>     see no reason to depend on NamingException when we have nothing to do
>     with LDAP.
>
>
> We still have some residual dependence on LDAP at higher levels like 
> when we talk about Index or Partition because of the nature of their 
> interfaces.  Partitions are still partial to the LDAP namespace or we 
> would be screwed.  They still need to be tailored to the LDAP 
> namespace.  There are in my mind 2 layers of abstractions and their 
> interfaces which I should probably clarify
>
> Partition Abstraction Layer
> --------------------------------
>   o layer between the server and the entry store/search engine 
> (eventually we might separate search from stores)
>   o interfaces highly dependent on the LDAP namespace
>
> BTree Partition Layer
> -------------------------
>   o layer between an abstract partition implementation with concrete 
> search engine which uses a concrete search engine based on a two 
> column db design backed by BTree (or similar primitive data structures)  
>   o moderately dependent on the namespace
>
> 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.

-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message