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