Re: [Objectbridge-jdo-dev] Introduction

[Thomas M. <tho...@ho...>]

Hi Joel,

Joel Shellman wrote:

<snip intro>
> 
>>What are your ideas?
>>Do you also focus on O/R mapping or do you want to build a JDO compliant
>>OODB?
>>
> 
> I'd like to see both done, though I see a huge advantage to having a JDO
> compliant OODB. It would make life so easy. That's why I've been working
> with Ozone (object db). 


I know Ozone a little. They also provide a ODMG Api, though not very 
complete.

> It has some things I don't like though, which is
> why I started Sparrow instead of just working with Ozone.
> 


What exactly is there in Ozone that you don't like?
Do you know DB40 (http://www.db4o.com)? it's a commercial OODBMS with a 
liberal licence for personal use. The db4o people are trying to 
establish lighweight statndard API for OO data access 
(http://www.odbms.org). OJB provides support for their S.O.D.A API 
already. The ultimate aim is to allow free choice of the persistent 
media (ODBMS or RDBMS).


> The bare minimum I see is:
> 
> 1) JDO front end with pluggable store
> 2) O/R mapping store
> 3) Object db store
> 


1) and 2) are exactly the scope of OJB-JDO
So their is really a large potential in joining our efforts!

This picture also looks very similar to the original JDO RI by sun.

I have an additional idea: what about using the OJB PersisteneBroker API 
as the store API? going this way we will have the following picture:

1.) JDO and ODMG front ends, both working against a PersistenceBroker 
kernel internally
2.) several PersistenceBroker implementations:
- for RDBMS (already implemented)
- for LDAP (partially implemented)
- for XML storage (some people already working on it)
- for OODB (to be done by Sparrow)

This would be a kind of "rosetta stone" of object persistence!


> Might also need to be a separated pluggable transaction manager and
> there's a good chance we would want to get a little more fine grained
> with the above.
> 


We are currently working on JTA and JCA support in OJB.


> My goal is to get to as close as:
>  - Drop in one or two jars and poof, you can now have persistent
> objects. That's all it takes.
> 
> The ideal might not be perfectly attainable, but I think it's possible
> to come at least very very close.


With a pure ODBMS approach this should be possible.
With a O/R approach it won't be that easy. (You must tell the RDBMS 
about primary keys, foreign keys and indexes which is not so easy to 
deduce from an object model...)
But it's not impossible to reach.

I believe we can save a lot of work with such a joint venture.

best regards,

Thomas