Re: [Springframework-developer] OJB support

[<jue...@we...>]

OJB supports cascading via "auto-update" and "auto-delete" attributes on =
collection and reference mappings. So yes, you can persist entire object =
graphs with a single store call, as long as the mapping is defined =
accordingly.

Not doing automatic change detection avoids a couple of issues:
- the overhead of snapshot comparison on flushing a Hibernate Session
- the strict reliance on identity in the first-level cache (also known =
as saveOrUpdate with "object already exists in Session" exception)
- bytecode post-processing for efficient change detection in JDO
- explicit detachment of persistent objects to allow for reuse outside a =
PersistenceManager in JDO 2

In combination with the relaxed implementation of lazy loading that does =
not depend on the PersistenceBroker that originally loaded the =
containing object, OJB's PersistenceBroker API incurs significantly less =
complexity to fight with than Hibernate's or JDO's semantics.

So if you don't need automatic change detection but still want one =
mapping per object that's used for all CRUD operations, OJB with the =
PersistenceBroker API might be a good choice. It avoids suffering from =
side effects of features that you don't need in the first place.

A further option is iBATIS SQL Maps, which is similar to the OJB =
PersistenceBroker in that it requires explicit store calls. However, it =
is conceptually one level below the PersistenceBroker: You define =
mappings for every single CRUD operation there, with full control over =
each SQL statement.

For complex object models, it's usually preferable to map each object =
once and let the persistence tool care about all SQL, so I'd vote for =
the OJB PersistenceBroker in that case, rather than iBATIS SQL Maps. OJB =
also provides more sophisticated querying facilities, not just plain =
SQL.

A great combination would be the persistence semantics of OJB's =
PersistenceBroker API and a text-based query language like HQL. That =
would be really useful for query-intensive scenarios that can easily =
live with explicit store calls. After all, I don't see anything that =
ties HQL to automatic change detection.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of James Cook
Sent: Wednesday, July 07, 2004 12:28 PM
To: spr...@li...
Subject: RE: [Springframework-developer] OJB support


> -----Original Message-----
> Of j=FCrgen h=F6ller [werk3AT]
> There's still OJB's full mapping capabilites, just
> with explicit store calls. For many applications, this will be all =
they
> need, respectively even the level they want to work on!

Sorry to ask this question without d/l OJB and looking at source, but =
I'm
real busy right now.

I'm really in favor of OJB's explicit store calls, since it allows us to =
use
our POJO domain objects as state objects without implementing versioning =
or
some attach/detach behavior. I just wanted to ask if you call =
save(entity)
on one object, does OJB use persistence by reachability to automatically
save all other objects mapped to the entity you persist?

Thanks





-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
digital self defense, top technical experts, no vendor pitches,=20
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer