| Seems to me that Alexander pretty much answered that question. If the source key is not itself auto-generated EOF will not be able to propagate to the destination, which EOModeler will enforce by disabling the option. Own's destination generally only makes sense for relationships that also use the cascade delete rule. However, these two concepts are NOT the same thing. Cascade delete rule applies to the deletion of the source object. Owns destination applies to objects that have been removed from a relationship. Here is how I keep this straight. Example 1 : Product <---->> ProductSupplier <<----> Supplier The join table [ProductSupplier] of a many-to-many relationship usually has a compound PK (the combination of the [Product] & [Supplier] PKs). EOF cannot generate keys for compound PKs, which means [Product] & [Supplier] need to propagate their PK to the FKs in [ProductSupplier]. Example 2: Customer <----> CustomerDetail (maybe not a great example but will work for this discussion) If [Customer] & [CustomerDetail] were both allowed to auto-generate PKs then EOF could not maintain the above "one-to-one" relationship. In order to make this work you would need to have [Customer] auto-generate a PK then propagate its PK to [CustomerDetail]. One possible downside to this type of relationship in EOF is that you will always have a row in [CustomerDetail] for each row in [Customer] (even if it contains only the PK propagated from [Customer]). EOF will not create [CustomerDetail] objects in a sort-of "on-demand" basis. There are other design patterns to work around this issue if it's important for particular cases. Example 3: Order <---->> Item In this case both [Order] & [Item] will auto-generate their own PKs. [Item] will, of course, contain the FK for the above relationship. In this case [Item] objects cannot stand on it's own. An order item makes no sense unless it's related to an order. Therefore, The Order ---->> Item side of the relationship should use both cascaded delete rule, and [Order] should "own" it's destination [Item] objects. This way if you use something like myOrder.removeObjectFromBothSidesOfRelationshipWithKey(someItem, "items") and never add that [Item] instance to another [Order] then EOF will delete the item instance from the object graph and delete the row from the database upon ec.saveChanges(). On Jul 17, 2006, at 10:44 AM, Mike Schrag wrote:
-- Robert Walker |
_______________________________________________ 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]
