directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Re: Why I think Spring + xbean is wrong ...
Date Sun, 09 Mar 2008 05:31:49 GMT
> Really? I wanted to work with you on this and saw you were using some 
> basis mapping technique.  I was wondering if this can be combined with 
> annotations somehow to drive the mapping in ways the user needs that are 
> outside of the basis mapping.

It definitely could.  That's the next phase of the DAS.  I have not found much time to work
on it lately.  To get the current version going I spent 3 months full time plugging away,
so my budget is pretty much spent, until I get some other projects out of the way, but it
does support taking any EMF graph and storing it in the DIT, hence it will support server.xml.

Acutally the mapping technique is fairly sophisticated braw.  It examines the EMF object reflectively
to figure out what the corresponding ObjectClass is, and if that object class does not exist,
it creates it.  Then it stores the Object in the DIT using that ObjectClass.  So if this were
relational, the DAS would first look at an Object to see whether the table exists.  Then if
it did not exist, it would create it, and then store the object as a row in the table that
it just created.

It also accounts for inheritance, so if the EMF instance being stored inherits from a super
type, then the DAS creates the corresponding ObjectClass that inherits from the parent ObjectClass.

So right now the DAS uses 0 configuration (Except for JNDI Connection parameters).  It just
figures out the schema automagically, creates it if it does not already exist, and goes from

>     Just load the generated model with server.xml, pass it to
> (model is a reference to the Object that is the root
>     element of server.xml), and it's instantly in the DIT.  Restoring it
>     from the DIT is the same.  DAS.load("DN of root server.xml
>     element");  So there's all sorts of benefits like that end up being
>     enabled, through use of EMF.
> Wow.  Sounds easy.  OK I need to find some time to pick your brain.

Pick away - You'll see there's not much up there :-).  Things come to me in flashes and then
their gone baby gone.  Seriously, I'll be happy to answer questions, it might just take me
a little time to refresh.  I need to write the guide for the current release anyways, so that
will be a good opportunity to get a push going.
>     One question that probably should come up during the JPOX
>     collaboration is whether it can support a similar capability.
> Right.  My fear is that we're going to try to bend the LDAP access model 
> to try to make it fit into the relational model and that would be a 
> mistake that will limit capabilities.

The one difference that helps LDAP DAS in this case is that EMF EObject's live in an XML namespace.
 I therefore used this concept to create ObjectClasses that match specific java classes. 

What JPOX could do, I think, is use the package namespace for the classes to generate ObjectClasses
that match each JPOX class, per object in a given graph.  Then just follow the same algorithm
that the LDAP DAS uses to read and write graphs.  Then the only difference would be that the
LDAP DAS uses an XML Namesapce to create unique ObjectClasses (Corresponding to Java Classes)
and the JPOX implementation uses java package namespaces instead.  (SDO has a ChangeSummary
that is used for updates and deletes, so we'd have to fingure out how JPOX wants to handle

This would guarantee a one to one mapping between java classes and ObjectClasses.  I think
the JPOX guys are pretty sharp though.  I'm sure they already have this stuff figured out.

One thing that has to be provided for queries like "SELCT BLAH FROM HOOOHAHHH" is that they
have to be translated into JNDI Speak.  In order to do this, additional context has to be
provided such that the translator understands what entry(s) HOOOOHAHHH corresponds to.  To
be more specific, it's "What namespace does HOOOHAHHH live in?".

Anyways - Just my 2 cents.  Hope it helps.  I would like to do a JPA facade on the LDAP DAS
later, and then I'll have a more concrete blue print of the concepts outlined above.

- Ole

View raw message