Re: Confused with delete rules in EntityModeler
Re: Confused with delete rules in EntityModeler
- Subject: Re: Confused with delete rules in EntityModeler
- From: David LeBer <email@hidden>
- Date: Tue, 26 Apr 2011 09:28:09 -0400
On 2011-04-26, at 9:08 AM, David Avendasora wrote:
>
> On Apr 26, 2011, at 8:20 AM, Markus Ruggiero wrote:
>
>> What confuses me is that there are delete rules for both directions of a relationship which makes no sense to me.
>
> Please give us more information about these two relationships. Cascade Delete rules should not go in both directions. I can't think of any valid uses, and it seems logical (To me. Shut-up Chuck) it would cause exactly what you are seeing.
A delete rule is not always cascade. So having delete rules in both directions is perfectly valid and often desirable. i.e: Cascade in one direction and deny in the other.
>
>> And what should those be for the flattened relationship?
>
> I'm guessing that they should be "nullify" or "do nothing"
Yes, only one delete rule should affect a given relationship. In fact, I always shy away from (nay, avoid completely) flattened relationships that hide objects I am actually interested in. In general, 'one path to the object' is the rule I try to follow.
>
>>
>> Here is the model:
>>
>> ElectronicDocument <-->>TextblockReference<<-->Textblock. TextblockReference is more than a simple m:n join table. However I have a flattened m:n relationship between ElectronicDocument (called textblocks) and Textblock (called documents) across TextblockReference. There are other entities hanging off TextblockReference: TextblockReferemce<-->>Params<-->>Data.
>
> All that seems perfectly fine.
>
>> When I delete an ElectronicDocument I want all associated TextblocReferences and everything hanging off it be gone, however Textblock should stay around but not have that particular ElectronicDocument object in its flattened relationship anymore.
>
> That is exactly how it should work. There's either something wrong in your model, or the Oracle cascade delete is the culprit. Let's hope it's the model. That's in your control to fix.
Yeah, many to many are usually modelled like: Many1 --cascade-> Many1Many2Join <--cascade-- Many2
;david
--
David LeBer
Codeferous Software
'co-def-er-ous' adj. Literally 'code-bearing'
site: http://codeferous.com
blog: http://davidleber.net
profile: http://www.linkedin.com/in/davidleber
twitter: http://twitter.com/rebeld
--
WOWODC 2011 : July 1-2-3, Montreal. http://wowodc.com
_______________________________________________
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