I cannot think of a use case for it. I'll defer to the description
of and explanation for this design decision on pages 520 and 524 of
_Java Persistence with Hibernate_:
<excerpt>
"Hibernate's transitive persistence model uses the same basic concept
as persitence by reachability: Object associations are examined to
determine transitive state. Furthermore, Hibernate allows you to
specify a cascade style for each association mapping, which offers
much more flexibility and fine-grained control for all state
transitions. Hibernate reads the declared style and cascades
operations to associated objects automatically.
By default, Hibernate doesn't navigate an association when searching
for transient or detached objects, so saving, deleting, reattaching,
merging, and so on, a Category has no effect on any child category
referenced by the childCategories collection of the parent. This is
the opposite of the persistence by reachability default behavior.
If, for a particular association, you wish to enable transitive
persistence, you must override this default in the mapping metadata.
These settings are called cascading options. They're available for
every entity association mapping (one-to-one, one-to-many, many-to-
many), in XML and annotation syntax.
[...]
Hibernate's association-level cascade style model is both richer and
less safe than persistence by reachability. Hibernate doesn't make
the same strong guarantees of referential integrity that persistence
by reachability provides. Instead Hibernate partially delegates
referential integrity concerns to the foreign key constraints of the
underlying SQL database.
There is a good reason for this design decision: It allows Hibernate
applications to use detached objects efficiently, because you can
control reattachment and merging of a detached object graph at the
association level. But cascading options aren't available only to
avoid unnecessary reattachment or merging: They're useful whenever
you need to handle more than one object at a time"
</excerpt>
With all that said, I don't immediately see any concrete examples in
the book that justify the final paragraph above. I didn't read every
page, either, so it may be in there somewhere.
I think to summarize, Hibernate (and thus, JPA) are counting on RI in
the RDBMS. This is an assumption that JDO is not about to make,
naturally.
At the same time, I think it's quite compelling to keep JDO's
available features and options as close to a superset of JPA as
possible. The ability to swap a JDO implementation into an
application that's coded to javax.persistence is an important goal.
If there is no JDO option to allow for turning off PBR, this goal
becomes a little less attainable.
I hate to sacrifice the conceptual integrity of the spec just to
'keep up' with features that may not even make sense in a JDO
context, so I certainly understand if this option gets vetoed.
- Chris
On Sep 19, 2007, at 4:57 PM, Craig L Russell wrote:
I think configurability of pbr is a mistake. I've never seen a case
where pbr was not what customers wanted. Anyone have an example?
Craig
On Sep 19, 2007, at 4:05 PM, cbeams wrote:
Curious if we have considered the idea of introducing standardized
configuration around persistence-by-reachability.
In JDO it is on by default for persist and update, and cannot be
turned off
In JPA it is off by default for persist and update, and can be
turned on/off
JPOX has introduced this configurability as an extension; perhaps
to keep abreast of JPA we should standardize it?
See http://www.jpox.org/docs/1_2/jdovsjpa.html for details on the
above
- Chris Beams
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
