openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: @Dependent annotation vs cascade=ALL
Date Thu, 08 Mar 2007 03:57:05 GMT
For the Hibernate-erati in the audience, this feature (JDO calls it  
"dependent" and JPA doesn't have it) is called cascade="all-delete- 


On Mar 7, 2007, at 6:28 PM, Kevin Sutter wrote:

> Thanks, Abe.  This explanation helps a great deal.  Should we  
> update the
> documentation with some of this information?
> Kevin
> On 3/7/07, Abe White <> wrote:
>> First, dependent should be compared to cascade=REMOVE rather than (or
>> in addition to) cascade=ALL.
>> cascade=REMOVE means "when I remove this parent instance immediately
>> cascade the remove operation to the referenced instance(s)".  It's a
>> very simple and naïve implementation and its behavior is mandated by
>> the JPA spec.
>> Dependent means "at the end of the transaction if the referenced
>> instance(s) are no longer referenced by this parent and have not been
>> assigned to any other parent, remove it/them".  It's much smarter /
>> more subtle.  For example if you null a dependent relation but don't
>> delete the parent, the referenced instance(s) will still be deleted
>> at the end of the transaction, because they are no longer referenced
>> by the parent (unless of course you assign them to some other parent
>> in the same transaction).
>> p.s. Note that dependent != db garbage collection.  A dependent
>> instance that is severed from its parent is deleted at the end of the
>> transaction unless assigned to another instance in the same
>> transaction -- we don't search the db to find out if any other parent
>> not involved in the transaction references the dependent instance
>> before deleting
>> it.__________________________________________________________________ 
>> _____
>> Notice:  This email message, together with any attachments, may  
>> contain
>> information  of  BEA Systems,  Inc.,  its subsidiaries  and   
>> affiliated
>> entities,  that may be confidential,  proprietary,  copyrighted   
>> and/or
>> legally privileged, and is intended solely for the use of the  
>> individual
>> or entity named in this message. If you are not the intended  
>> recipient,
>> and have received this message in error, please immediately return  
>> this
>> by email and then delete it.

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message