Re: Owns Destination & Deny
Re: Owns Destination & Deny
- Subject: Re: Owns Destination & Deny
- From: David Avendasora <email@hidden>
- Date: Fri, 6 Mar 2009 09:00:29 -0600
On Mar 6, 2009, at 7:46 AM, Susanne Schneider wrote:
Hi Dave,
I think if Owns Destination is checked, then the following
should automatically happen:
1) Delete Rule should be set to "Cascade" and drop down disabled
(anything else is in conflict with Owns Destination).
Not 100% sure on that. Deny means you can't delete the parent
if there are children. It might be reasonable to have this
restriction. The children would have to be manually deleted
before the parent could be deleted.
So if the only thing that Owns Destination does is cause the child
to be deleted if the parent no longer exists but the Deny delete
rule stops you from doing that, how can the Owns Destination
setting have any meaning?
That is not the meaning. What this option is for that if you remove
the child from the relation to the parent (parent otherwise
unchanged and still existant), the child will get deleted by itself
without you have to delete it explicitly.
This is very comfortable if you only have a change in the set of
relations of the parent without a handle to the "lost" childs.
If I understand what you and Flor are saying is that if you have a
child entity, and you set it's relationship to the parent to null then
the child will simply get deleted. That much makes perfect sense.
One of the ways (but not the only one) the parent relationship can be
set to null is when the parent is deleted. But if the Deny delete rule
is set, you can't delete the parent if children exist. This also makes
sense.
But this does not prevent you from simply calling
setParentRelationship(null) on the child. When you do this, the child
will then be deleted automatically without further effort.
So, in the end, the only way using Owns Destination and Deny in
combination on the Parent-to-Child relationship is different from
simply having Deny set is that if the inverse Child-to-Parent
relationship is set to null, the child will be deleted.
This is very weird because how a relationship is configured can have
an impact on what happens when the inverse relationship is modified.
EOF says "Oh, you want that relationship to be null? Let me check if
the inverse relationship is set to Owns Destination. Yep, it is.
Delete this instead of just modifying the relationship."
Am I grasping the concept fully now?
Now, let's throw in the likelihood (necessity?) that the Child-to-
Parent relationship is Required. Now you can't set it to null. You can
delete the child, or change it's parent to another parent, but not
nullify the relationship. Now there is no added benefit to having the
Parent-to-Child relationship marked as Owns Destination if it has a
Deny delete rule.
You can't really have the Child-to-Parent as optional, because the
Owns Destination means that the Child cannot exist without the Parent,
so a Child with a null Parent relationship is not valid. So the Owns
Destination and Optional settings are in conflict.
So that leads me back to the belief that adding an Owns Destination to
a relationship with a Deny delete rule is meaningless, because
Deleting the parent cannot delete the child because of the Deny delete
rule, and the child cannot exist with a null Parent because the Owns
Destination says it can't. So what's the added benefit of Owns
Destination?
Is it just that if you set the required Parent relationship on the
Child to null you won't get a validation error when you save because
the Child will get deleted before validation rules are applied to it?
I think I just answered my own question.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden