Hi again, Laurie Harper wrote:
The query abstraction was the most simple thing: we just consented to use the OJB query API! It's really easy to translate Toplink Expression builder queries to OJB queries and vice versa.
To write a plugin; I meant it was a lot of work to write the initial query abstraction. Or is that a mis-conception on my part?
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.
But there are some more subtle gotchya's -- like the way ODMG requires you to lock an object to a transaction before you modify it but JDO doesn't. I'm sure there are others :-)
sure! Our transaction wrapper relies on explicit locking.
Being an optimist, I assume that SUNs JDO RI does not contain any bugs and is fully compliant to the spec.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.
So the obvious question is: what benefits will OJB's native JDO implementation provide when it's ready?
Thus the OJB native implementation we have no *functional* benefits.
But I see several non-functional benefits:
- It will be an *OSS* JDO implementation
- thus the community will be allowed to modifiy and reuse the code
without getting trapped in copyright and license issues.
- thus it's much easy to fix bugs and implement future improvements.
- It can be optimized for the OJB PB (the JDORI seems to be optimized
for the special features of FoStore and does a several things like
attribute fetching that do not make much sense with a PB backend)
- Having an abstract Object Transaction Management layer does also
have several benefits. E.G. Users that don't want to stick to ODMG or
JDO could use it (or write derivates) as a persistence API.
Or, put another way, what are the limitations of the JDORI + OJB approach?
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...
I had a look at doing this but got a bit entangled and then had to switch to something else. If I get the chance to try again I assume you'll be interested in the results ;-)
sure! 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]>
