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 there.
Just load the generated model with server.xml, pass it to
DAS.save(model) (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 that.)
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.
Cheers,
- Ole
