Re: Traversing keys or EOEntities
Re: Traversing keys or EOEntities
- Subject: Re: Traversing keys or EOEntities
- From: Art Isbell <email@hidden>
- Date: Wed, 12 Feb 2003 11:42:19 -1000
On Wednesday, February 12, 2003, at 10:27 AM, Jonathan Fleming wrote:
this is the relationship:
tbClient-(owns tbClientData, propagates primary key) > <
(mandatory)-tbClientData
From the code below I am trying to get data to go into the object
tbClientData but I keep getting this error message -- The tbClient
property of TbClientData must have a TbClient assigned
The code looks fine, so there must be something wrong with your model
unless the error message is referring to a TbClientData object
somewhere else in your code. Where in your code is the error message
being generated? How have you defined the TbClientData.tbClient
relationship?
Note that you are modeling a potentially difficult situation. It
appears that TbClient and TbClientData share the same primary key. A
primary key can never be null. In the relationships between these
objects, the primary key is also the foreign key. A foreign key must
be null when the relationship is null, but because the foreign key and
primary key are the same, the foreign key can never be null. So you
can never allow a TbClient or TbClientData object to be saved without a
related object existing. But you've set the "Owns Destination"
property for TbClient.tbClientData which means that when a TbClientData
object is removed from the TbClient.tbClientData relationship, it will
be automatically deleted from the database when the editing context is
saved. Hopefully, EOF is smart enough to delete this TbClientData
before it updates its tbClient relationship to null because it is no
longer related to a TbClient object. But to prevent the mandatory
TbClient.tbClientData relationship being null, you must have assigned
another TbClientData object to the TbClient.tbClientData relationship
after removing the previous TbClientData object and prior to saving.
If a TbClient can ever be saved without a TbClientData object, you
can't model the TbClient.tbClientData relationship as a mandatory
to-one relationship. Instead, it must be an optional to-many
relationship in which the primary key is not propagated, a foreign key
attribute must be added to TbClientData, and TbClientData must get its
primary key from the database in the usual fashion.
Does this describe what you are doing or likely to do? Do you really
need both inverse relationships to be class properties?
Art
http://homepage.mac.com/aisbell/
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.