You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2004/03/26 16:12:01 UTC
JDO (and OTM additions) (and maybe a PB addition)
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
Re: JDO (and OTM additions) (and maybe a PB addition)
Posted by Brian McCallister <mc...@forthillcompany.com>.
On Mar 26, 2004, at 1:23 PM, Thomas Mahler wrote:
> I'm not absolutely sure about 1). Maybe it could be implemented as a
> specific FieldAccess strategy on the PB level.
That is exactly what I want to do, sorry it wasn't clear =)
> But I see at least 2) and 3) above the PB layer (presumably on the OTM
> layer).
> Why to you think that those should be handled on the PB level?
Adding the interface at the PB level would be solely be because of the
PB level FieldAccess strategy. It could be purely in the o.a.ojb.jdo
namespace if we wanted -- just didn't know if we wanted to provide
bytecode-enhanced optimizations as an option in general (no dependency
on the javax.jdo namespace).
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO (and OTM additions) (and maybe a PB addition)
Posted by Thomas Mahler <th...@web.de>.
Hi Brian,
I agree with you that all three points are necessary to get a working
JDO implementation.
But I see at least 2) and 3) above the PB layer (presumably on the OTM
layer).
Why to you think that those should be handled on the PB level?
I'm not absolutely sure about 1). Maybe it could be implemented as a
specific FieldAccess strategy on the PB level.
cheers,
thomas
Brian McCallister wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org