objectbridge-jdo-dev

AW: [Objectbridge-jdo-dev] JDO implementation

[Mahler T. <tho...@it...>]

Hi Sebastian,

<snip intro>
> 
> in fact I'm really interested in helping on a jdo open-source 
> implementation 
> and I've already done some work at home. Now, I've found ojb 
> and I'm trying 
> to investigate, how easy it would be, to use it as the 
> storage backend. 
> However, this is somewhat difficult, as the documentation 
> about the internal 
> things (not how to use it from a user perspective) is not 
> always optimal --- 
> which I probably wouldn't do better on my own projects... :(
> 

If you have a short look at Travis' implementation you will see that it does
not make use of any internal OJB structures. It is a simple
PersistenceBroker API client application. 

The same holds true for the OJB-ODMG implementation: it is just a client
using the PersistenceBroker Interface.

I explained this layered approch in my jdo-psoposal:
http://objectbridge.sourceforge.net/jdo/jdo-proposal.html

But I agree to you: the documentation of OJB internals is far from being
complete. It will be a good idea to improve it!

> So, I'll certainly stay on this list and help if I can...

fine, all help is appreciated.

ciao,

Thomas

> ciao Sebastian
> 
> 
> -- 
> Sebastian Kanthak    |    seb...@mu...
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
> 

Re: AW: [Objectbridge-jdo-dev] JDO implementation

[Sebastian K. <seb...@mu...>]

Hi Thomas,

On Thursday 23 May 2002 09:52, Mahler Thomas wrote:
> If you have a short look at Travis' implementation you will see that it
> does not make use of any internal OJB structures. It is a simple
> PersistenceBroker API client application.
>
> The same holds true for the OJB-ODMG implementation: it is just a client
> using the PersistenceBroker Interface.
>
> I explained this layered approch in my jdo-psoposal:
> http://objectbridge.sourceforge.net/jdo/jdo-proposal.html

I've already inspected Travis's implementation carefully and crawled through 
the ojb sources (especially the odmg and the broker part) a bit and read your 
proposal. However, as I tried to explain in my earlier thread with Travis 
last week, I don't think, that a compliant JDO implementation is possible 
that way.

As all communication with the persistence capable instance should be done via 
the StateManager, we probably would require a new PersistentField 
implementation. As far as I see, objects are created by RowReaders. The 
DefaultRowReaderImpl uses either a multi-arg constructor or reflection to 
create new objects. We would probably need another implementation, because 
JDO objects should be created via JDOImplHelper and one needs a StateManager 
for the new instance.

Another point is about lazy-materialization. Currently, this is done via 
Proxy objects. However, this can be done better in JDO (not requiring an 
interface type anymore) with help of the StateManager. I'm not sure, where 
this stuff is located, so I don't have an idea, what changes would be 
necessary.

Probably there are easier solutions than I have suggested, because I don't 
know the ojb source well enough.

Another point is JDO's notion of a "default fetch group". The idea is, to 
load all fields in this group together, and other fields on-demand. I think, 
ojb loads everything belonging to one object at once. As this is not require 
by the spec, it would be ok, but one could think about, if this 
default-fetch-group would give us a better performance in some situations.

> fine, all help is appreciated.

As you've probably noticed, I've already started thinking, how to use ojb for 
a jdo implementation, but are still in the state of analyzing, how ojb 
exactly works and where the best points to start form are. Perhaps some ojb 
developer can give me some hints on the points mentioned above.

ciao Sebastian

-- 
Sebastian Kanthak    |    seb...@mu...

Re: AW: [Objectbridge-jdo-dev] JDO implementation

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

Hi Sebasthian,

Sebastian Kanthak wrote:

<snip>


> I've already inspected Travis's implementation carefully and crawled through 
> the ojb sources (especially the odmg and the broker part) a bit and read your 
> proposal. However, as I tried to explain in my earlier thread with Travis 
> last week, I don't think, that a compliant JDO implementation is possible 
> that way.
> 


I agree, a *lot* of things are missing: (Transaction management, 
Instance Lifecycle Management, Dirty detection, partial loading, JDOQL, 
etc.) This will require a lot more thinking, no doubt!


> As all communication with the persistence capable instance should be done via 
> the StateManager, we probably would require a new PersistentField 
> implementation.


ACK

> As far as I see, objects are created by RowReaders. The 
> DefaultRowReaderImpl uses either a multi-arg constructor or reflection to 
> create new objects. We would probably need another implementation, because 
> JDO objects should be created via JDOImplHelper and one needs a StateManager 
> for the new instance.
> 


ACK


> Another point is about lazy-materialization. Currently, this is done via 
> Proxy objects. However, this can be done better in JDO (not requiring an 
> interface type anymore) with help of the StateManager. 


ACK

> I'm not sure, where 
> this stuff is located, so I don't have an idea, what changes would be 
> necessary.


For ojb.broker.metadata.PersistentField and for 
ojb.broker.accesslayer.RowReader you just have to code a new (JDO 
compliant) Implementation and you have to tell OJB to use these 
implementations in OJB.properties in the respective entries.

The StateManager stuff will be one of the most interesting (and 
difficult) things.
But implementing a lazy load mechanizm without OJB proxies will be quite 
simple:

ReferenceDescriptors and CollectionDescriptor will be declared as *not* 
using proxies and as *not* using automatic load (this would be declared 
in the repository.jdo file).
WIth these simple settings OJB won't load references and collection 
attributes. So the StateManager can implement its own logic for loading 
references and collections. (Of course it can again use the 
PersistenceBroker and Query Objects to load those attributes.)


> 
> Probably there are easier solutions than I have suggested, because I don't 
> know the ojb source well enough.
> 


I think you found the right "hooks"!


> Another point is JDO's notion of a "default fetch group". The idea is, to 
> load all fields in this group together, and other fields on-demand. I think, 
> ojb loads everything belonging to one object at once. As this is not require 
> by the spec, it would be ok, but one could think about, if this 
> default-fetch-group would give us a better performance in some situations.
> 


This is also possible with OJB: OJB does load only those attributes 
defined in an Objects ClassDescriptor. It is very easy to modify 
ClassDecsriptors at runtime to fill only specific attributes!


> 
>>fine, all help is appreciated.
>>
> 
> As you've probably noticed, I've already started thinking, how to use ojb for 
> a jdo implementation, but are still in the state of analyzing, how ojb 
> exactly works and where the best points to start form are. 


No problem! OJB has grown quite big (> 450 classes) and it takes some 
time to get familiar with it.


ciao,

Thomas