db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <mccallis...@forthillcompany.com>
Subject Re: State Tracking
Date Fri, 23 Jul 2004 12:32:41 GMT
On Jul 23, 2004, at 8:20 AM, Armin Waibel wrote:

>> This means re-implementing a lot of what is in the OTM, however, with 
>> the OTM there, and experience gained working with it, this should be 
>> quite doable.
>> I am *not* going to initially aim for the full set of pluggable 
>> thingies the OTM does. Rather, I will work on making it possible to 
>> plug them, but not bother implementing until a need is expressed.
>> I have a good start on a state management and object graph 
>> manipulation library with no OJB dependencies.  I am thinking of 
>> putting it in
>> commons-db and letting OJB be dependent on it.
> Is this really possible without complex operations or mappings? Don't 
> you need the proprietary object metadata classes (PK keys, FK, 
> relationships, ...) to handle this stuff?

Right now it behaves in terms of Java object graphs, with no knowledge 
that they may be being mapped somewhere. Restoration and tracking of 
the graph is very possible.

Handling statement reordering, etc, requires knowing the pk/fk 
relationship information, and being able to sort them based on that. 
That information along with access to the whole graph as a 
bi-directional graph instead of normal reference/uni-directional lets 
you work in the relational sense, methinks. Haven't actually 
implemented the statement mucking yet, just been working on the graph 
manipulation and state management required for JDO.

I want to check in the code somewhere, but until we figure out where 
(ojb, db-commons,?), I just bundled a tarball at
which has 1 failing unit test (where I left off on making the unit of 
work/state trackers properly serializable).

Adding callback hooks for state transitions and begin/commit/rollback 
should allow the extraction of all the information needed to push 
things into the PB correctly. The code is roughly based on the dirty 
stuff, but without the OJB dependency.


To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org

View raw message