Hi all,

On Jan 16, 2008 5:26 AM, Emmanuel Lecharny <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.
 

More than that, we may have to build tools on top of this layer,

Yes good point I did not consider this however please take a look below how I describe some of these layers.
 
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.
 

Option 1 will conflict in some way with JDBM and JE design, as stated by
PAM.

Yeah you're right.
 

I would favor Option 3 then.

The good thing is that defining a new set of exceptions is not really
that hard :)

Right and it is neutral to all implementations - just slightly more repetitive work for me but no big deal.

Alex
 


Pierre-Arnaud Marcelot wrote:
> Hi Alex,
>
> Option 1 seems the easiest solution but will it work with an exception
> based on DatabaseException ?
> I don't think... Reading the JE API, DatabaseException extends
> Exception and not IOException.
>
> I like Option 3 and the idea to encapsulate the exception thrown
> inside our "own exception". But it means surely a lot of refactoring...
>
> My 2 cents. ;)
>
> Pierre-Arnaud
>
> On Jan 15, 2008 11:45 PM, Alex Karasulu <akarasulu@apache.org
> <mailto:akarasulu@apache.org >> wrote:
>
>     Hi all,
>
>     Different underlying stores have different kinds of checked
>     exceptions they throw at the lowest level.  For example JDBM is
>     humble and just uses IO exceptions.  The JE authors use an
>     exception hierarchy based on DatabaseException.  I was wondering
>     if there was a preference out the base class for what exceptions
>     are thrown from partitions?  Right now there are a few options:
>
>     (1) Throw exceptions that extend IOException (works well with JDBM)
>     (2) Throw NamingExceptions works well with Java Naming but we have
>     a bad taste in our mouths from this.
>     (3) Create our own base class for exceptions thrown at these lower
>     layers like say PartitionException
>
>     Right now I went with IOException but I'm thinking it might be
>     biased towards a particular partition implementation.  Does anyone
>     have some opinion one way or the other?
>
>     Alex
>
>
>
>


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