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: Layer Design [was Release OJB 1.0.01]
Date Sun, 01 Aug 2004 17:16:31 GMT
On Aug 1, 2004, at 12:48 PM, Thomas Dudziak wrote:

> How does that work together with caches, esp. the two-level cache that 
> Armin works on ?

The caching Armin is doing is PB level, and that is where caching 
belongs, in my mind. Object state tracking, and object level 
transactions can, and should, work independently of the relational 
backend (which the PB bridges). We are really talking about the design 
of higher level persistence API's above the O/R mapping layer. PB does 
O/R mapping beautifully. People want higher level API's built on that 
though; annoying things, those users, grrr ;-)

> I'm not entirely sure how much of that is visible to the outside (e.g. 
> the OJB users) anyway, and if it usable by PB, ODMG and JDO, then I'm 
> all for adding it to OJB.

Visibility:
	From JDO: none
	From ODMG: none
	From PB: 100%

The stack I see for JDO is either:


state management:  JDO -> Grafolia -> Lonely -> PB -> RDBMS

(where Grafolia is the working name I have been using for state 
tracking, and Lonely is the working name I have not done any work on, 
but have conceptual model of, for isolation). This looks like a lot of 
layers, but is, I suspect, going to be a lot less code than the current 
OTM which does it all.

or

state management:  JDO -> OTM -> PB -> RDBMS


Where the OTM handles state and isolation together like now, as well as 
understanding OQL, etc.

We keep re-implementing concerns in multiple levels (auto-* vs 
otm-dependent vs odmg reqs, etc) and we should probably stop this 
now-ish =) I tend to think that the auto-retrieve (getting the data) 
belongs in the PB layer , auto-delete and auto-update (deciding what to 
change) belong in the graph management layer (ODMG, OTM, Grafolia).


Speaking of JDO, a similar split to break dependencies, which is what I 
have interpreted Thomas D. to be doing with the new OQL and JDOQL 
compilers (btw, Thomas D, go join the JDO2 EG -- because of NDA I 
cannot tell you why, though). Having arbitrary syntax compiled to an 
AST we understand, which then can be directly assembled into a PB query 
will be very very nice as adding a query language simply means 
implementing a parser which will generate our AST.

-Brian



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


Mime
View raw message