Mailing-List: contact ojb-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "OJB Developers List" <ojb-dev@db.apache.org>
Message-ID: <40647531.4010906@web.de>
Date: Fri, 26 Mar 2004 19:23:45 +0100
From: Thomas Mahler <thma32@web.de>
Reply-To: thma@apache.org
Organization: Apache Foundation
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821
MIME-Version: 1.0
To: OJB Developers List <ojb-dev@db.apache.org>
Subject: Re: JDO (and OTM additions) (and maybe a PB addition)
References: <Pine.GSO.4.21.0402231853190.12646-100000@pille>
 <403AFA98.30308@web.de>
 <C91FDA16-66D5-11D8-8268-000A95782782@forthillcompany.com>
 <EEE25ABC-7F37-11D8-AE70-000A95782782@forthillcompany.com>
In-Reply-To: <EEE25ABC-7F37-11D8-AE70-000A95782782@forthillcompany.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: thma32@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