You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2007/03/07 20:47:07 UTC
@Dependent annotation vs cascade=ALL
Hi,
Can someone explain the difference between the @Dependent annotation and the
cascade=ALL (or any of the cascading actions) element of the relationship
annotations? From what I can tell in the documentation, they provide
similar function. Maybe the @Dependent (and associated @ElementDependent
and @KeyDependent) annotations pre-date JPA? Like they were required for
previous versions of Kodo? I can understand that we need to support the
previous users of Kodo, but should we update the documentation accordingly?
Maybe I'm missing the intent of these annotations. I don't mind being
educated. Thanks!
Kevin
Re: @Dependent annotation vs cascade=ALL
Posted by Kevin Sutter <kw...@gmail.com>.
Finally remembered to integrate the doc changes for this conversation. I
just put a couple of pointer references between the JPA
CascadeType.REMOVEand the OpenJPA @Dependent annotation sections. SVN
revision #518192.
On 3/8/07, Craig L Russell <Cr...@sun.com> wrote:
>
> Hi Kevin,
>
> On Mar 8, 2007, at 8:45 AM, Kevin Sutter wrote:
>
> > Abe,
> > Your explanation in your reply was much clearer (IMHO) than the
> > current
> > documentation. I will take a stab at improving the wording so that
> > the
> > meaning and differences are more pronounced. I will also link the two
> > sections of the document. Thanks.
> >
> > One clarification... Using Magazine and Article from the doc's
> > example, if
> > a field (Article) is marked as @Dependent and the owning object
> > (Magazine)
> > is deleted, then cascading this delete operation down to the
> > Article object
> > is the same as specifying cascade=REMOVE (or ALL) on the relationship
> > annotation. Correct?
>
> Yes. From the perspective of the remove behavior, cascade=REMOVE or
> @Dependent will have the same effect.
>
> > It seems that the added benefit of the @Dependent
> > family of annotations is to aid with the orphan object deletion
> > when the
> > Article field is just nulled out.
>
> Right. Usually, dependent relationships are modeled as one-to-many
> relationships, but they apply equally to single-valued relationships.
> As far as I know, they have no value when used with many-to-
> relationships, though.
>
> Craig
> >
> > Thanks,
> > Kevin
> >
> > On 3/8/07, Abe White <aw...@bea.com> wrote:
> >>
> >> > Thanks, Abe. This explanation helps a great deal. Should we
> >> > update the
> >> > documentation with some of this information?
> >>
> >> As far as I can tell the documentation on cascade=DELETE and the
> >> documentation on the Dependent metadata extension already contains
> >> everything I said. Feel free to change it, though.
> >> _____________________________________________________________________
> >> __
> >> 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 http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
Re: @Dependent annotation vs cascade=ALL
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Kevin,
On Mar 8, 2007, at 8:45 AM, Kevin Sutter wrote:
> Abe,
> Your explanation in your reply was much clearer (IMHO) than the
> current
> documentation. I will take a stab at improving the wording so that
> the
> meaning and differences are more pronounced. I will also link the two
> sections of the document. Thanks.
>
> One clarification... Using Magazine and Article from the doc's
> example, if
> a field (Article) is marked as @Dependent and the owning object
> (Magazine)
> is deleted, then cascading this delete operation down to the
> Article object
> is the same as specifying cascade=REMOVE (or ALL) on the relationship
> annotation. Correct?
Yes. From the perspective of the remove behavior, cascade=REMOVE or
@Dependent will have the same effect.
> It seems that the added benefit of the @Dependent
> family of annotations is to aid with the orphan object deletion
> when the
> Article field is just nulled out.
Right. Usually, dependent relationships are modeled as one-to-many
relationships, but they apply equally to single-valued relationships.
As far as I know, they have no value when used with many-to-
relationships, though.
Craig
>
> Thanks,
> Kevin
>
> On 3/8/07, Abe White <aw...@bea.com> wrote:
>>
>> > Thanks, Abe. This explanation helps a great deal. Should we
>> > update the
>> > documentation with some of this information?
>>
>> As far as I can tell the documentation on cascade=DELETE and the
>> documentation on the Dependent metadata extension already contains
>> everything I said. Feel free to change it, though.
>> _____________________________________________________________________
>> __
>> 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 http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: @Dependent annotation vs cascade=ALL
Posted by Kevin Sutter <kw...@gmail.com>.
Abe,
Your explanation in your reply was much clearer (IMHO) than the current
documentation. I will take a stab at improving the wording so that the
meaning and differences are more pronounced. I will also link the two
sections of the document. Thanks.
One clarification... Using Magazine and Article from the doc's example, if
a field (Article) is marked as @Dependent and the owning object (Magazine)
is deleted, then cascading this delete operation down to the Article object
is the same as specifying cascade=REMOVE (or ALL) on the relationship
annotation. Correct? It seems that the added benefit of the @Dependent
family of annotations is to aid with the orphan object deletion when the
Article field is just nulled out.
Thanks,
Kevin
On 3/8/07, Abe White <aw...@bea.com> wrote:
>
> > Thanks, Abe. This explanation helps a great deal. Should we
> > update the
> > documentation with some of this information?
>
> As far as I can tell the documentation on cascade=DELETE and the
> documentation on the Dependent metadata extension already contains
> everything I said. Feel free to change it, though.
> _______________________________________________________________________
> 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.
>
Re: @Dependent annotation vs cascade=ALL
Posted by Abe White <aw...@bea.com>.
> Thanks, Abe. This explanation helps a great deal. Should we
> update the
> documentation with some of this information?
As far as I can tell the documentation on cascade=DELETE and the
documentation on the Dependent metadata extension already contains
everything I said. Feel free to change it, though.
_______________________________________________________________________
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.
Re: @Dependent annotation vs cascade=ALL
Posted by Kevin Sutter <kw...@gmail.com>.
Ahhh... In my conversation with this OpenJPA customer, he had mentioned a
"delete orphan" feature. Now I know where the reference came from. Thanks.
Kevin
On 3/7/07, Craig L Russell <Cr...@sun.com> wrote:
>
> For the Hibernate-erati in the audience, this feature (JDO calls it
> "dependent" and JPA doesn't have it) is called cascade="all-delete-
> orphan".
>
> Craig
>
> 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 <aw...@bea.com> 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 http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
>
Re: @Dependent annotation vs cascade=ALL
Posted by Craig L Russell <Cr...@Sun.COM>.
For the Hibernate-erati in the audience, this feature (JDO calls it
"dependent" and JPA doesn't have it) is called cascade="all-delete-
orphan".
Craig
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 <aw...@bea.com> 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 http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: @Dependent annotation vs cascade=ALL
Posted by Kevin Sutter <kw...@gmail.com>.
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 <aw...@bea.com> 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.
>
Re: @Dependent annotation vs cascade=ALL
Posted by Abe White <aw...@bea.com>.
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.