db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Braeuchi <jbraeu...@gmx.ch>
Subject Re: Layer Design [was Release OJB 1.0.01]
Date Thu, 05 Aug 2004 17:23:29 GMT
hi brian,

Brian McCallister schrieb:

> 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 ;-)

it will be hard to remove existing functionality from pb-api because it's 
already used. but i also prefer a clean layering.

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

i do not know how many users actually work with otm, so maybe we should replace 
it completely with the new components.
> 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).

removing auto-update/delete from pb-api could make this api quite unusable ?


> 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

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

View raw message