db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cbeams <cbe...@gmail.com>
Subject Re: Configurable persistence by reachability in JDO 2.1?
Date Thu, 20 Sep 2007 01:05:15 GMT
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_:

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

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,  

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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message