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...