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 protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
