db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject JDO (and OTM additions) (and maybe a PB addition)
Date Fri, 26 Mar 2004 15:12:01 GMT
Have been reading more JDO spec stuff and while I dislike how much it 
specifies still -- their heart is definitely in the right place.

Some proposals in regard to approaching a JDO api and relations to the 
rest of OJB:

1) Add a FieldAccessor that talks to PersistenceCapable (PC) instance, 
or that talks to the interface proposed in (3)

2) Add a swizzling strategy and EditingContext which don't use copies, 
but direct flag fields as dirty etc via the PC object. This allows much 
faster determining of what needs to be updated on an OTM tx commit, and 
requires a lot less memory as clones of persistent fields don't need to 
be kept around in the editing context.

3) Provide an o.a.o.[broker|otm].??? level interface to provide access 
to bytecode enhanced classes' fields etc in order to provide the 
improved efficiency outside of just JDO (ODMG on OTM etc).

-Brian

On Feb 24, 2004, at 9:28 AM, Brian McCallister wrote:

> On Feb 24, 2004, at 2:17 AM, Thomas Mahler wrote:
>
>> I'm also voting for a full implementation. But a "Lite" 
>> implementation could be a start.
>
> I like the JDO-lite, personally, as I think most of the JDO SPI is 
> terrible -- but that is just me believing a spec should declare a 
> client API and not try to tell you how to implement it ;-) I recognize 
> the value in a full implementation though =)
>
> I am willing to be that if we wanted to we could make an 
> implementation which supports both methods -- you can use the SPI if 
> you feel like it, but if you don't we don't. The SPI interfaces would 
> simply be a facade over calls back into the OTM state tracking, and 
> the real work from the client API would not even use the SPI 
> implementation.
>
>>> There at least four that I know of:
>>> http://jpox.sourceforge.net/
>>> http://xorm.sourceforge.net/
>>> http://speedo.objectweb.org/
>>> http://tjdo.sourceforge.net/
>
> JPox and TJDO have compatible licenses, Speedo and JPox don't have 
> compatible licenses.
>
> I nosed through the TJDO source last night and it is mostly clean 
> looking, but it pretty much wraps database transactions directly. In 
> theory they have the  most to gain from working together as the 
> mapping system is quite weak (schema generation only -- no mapping to 
> existing schema). It looks pretty monolithic, however.
>
> Haven't looked at JPox yet.
>
> -Brian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message