On Apr 26, 2011, at 9:28 AM, David LeBer wrote: > > 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.
Er.. Yes. That's what I meant. "Cascade Delete Rules" should not go in both directions. Other combinations certainly can. > >> >>> 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. Absolutely! +1,000,000. EOF gets horribly confused if you have multiple paths. Never, never, never have more than one relationship in an Entity share a FK, or have a FK be a class attribute because you can set one without setting the other, or set them independently to different values, try to delete one relationship and the other still sees it as being valid but the object is long gone. Hmmm. That last one sounds familiar... :-) > >> >>> >>> 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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
