Hi again Laurie, Laurie Harper wrote:
Thomas Mahler wrote:In fact we are doing this in my companies business frameworks. We support TopLink and OJB as strategic persistence layers. (There is also a LDAP implementation)
Proprietary or based on another persistence framework? I started out wanting to use LDAP but switched to a database because I couldn't find any working LDAP mapping frameworks...
It's a closed source inhouse product. So I can't shair sources...
exactly. our tx.register(instance) is delegated to an ODMG tx.lock(instance);A customer may choose to use either OJB or TopLink. We provide a very thin abstraction layer above the persistence layers. 1. There is a Session interface used to connect to the backend datastore with username and password. 2. there is a Transaction (or unit-of-work) interface with methods for beginning, commiting and aborting transactions, methods to register objects to the transaction and a methods to perform Queries.So that would be the equivalent of ODMG's lock()?
3. A query API with an AST representation of queries. (We are using the OJB Query package here). A good choice could be to use SODA (http://www.odbms.org) as abstract query syntax!
This strikes me as being where the work is here; it's sort of painful to have to write a query API to abstract away competing standards :-)
All you have to do to plug in a concrete persistence layer is to 1. provide a SessionImpl, 2. provide a TransactionImpl 3. provide a Translator that translates the AST queries representation into the query representation of the concrete persistence layer. Building this translator for TopLink was *very* easy, as the TL expressionbuilder is quite similar to OJB queries.
Easy once you've already got the framework and just need to write the glue, though, right?
It was only a few days work.
Our approach is minimalistic, but did work even for large scale applications!
From another posting I guess you can't share any of this?
Yes, it's closed source.
To be honest, I'd rather learn enough about ODMG and JDO to pick one and avoid the need to write the query abstraction component of the framework you've described.ODMG and JDO are *very* similar from an API point of view. The main difference I see is the Query language.
So it won't be a big deal to start with ODMG today and to switch to a JDO implementation later.
Do I understand correctly that the JDO reference implementation provider you posted last week means that I could adopt JDO with ODMG now? Or is JJDO RI + OJB still a limitted feature set?The JDORI + OjbStore Solution should be a as complete as the Default RI 1.0 from SUN.
The OjbStore simply replaces the default FoStore to provide an O/R backend instead of an file based backend.
But I did not have the time to run the JDORI testsuite or the JDO TCK against this solution.
I assume there are still some bugs or shortcomings...
cheers,
Thomas
L. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
