Re: Traversing keys or EOEntities
Re: Traversing keys or EOEntities
- Subject: Re: Traversing keys or EOEntities
- From: "Jonathan Fleming" <email@hidden>
- Date: Thu, 13 Feb 2003 01:04:33 +0000
Thanks for that Art, you arte absolutly spot-on, on all counts of your
deduction.
Having read your piece I can see that I don't need the mandatory
relationship because a tbClientData does not have to exsist with a tbClient
and so it can or should be able to save without reference to a tbClient.
My logic was that since there is only one tbClientData object that will ever
belong to a tbClient then a oneToOne relationship would surfice, however,
between you highlighting that i was running into a potentially difficult
situation with this oneToOne relationship and Jonathan Rochkind noting that
he does his level best to steer clear of "owns destination" options in these
situations, I think i'll avoid oneToOne relationships as much as is
possible. they're begining to sound like a nightmere.
I'm going to change the EOModel to produce tbClient with a oneToMany>>
relationship to tbClientData, therefore tbClientData with hava a <ToOne
relationship back.
Does that seemingly safer, simpler option sound correct to you?
Kind regards
Jonathan
From: Art Isbell <email@hidden>
To: email@hidden
Subject: Re: Traversing keys or EOEntities
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.
_________________________________________________________________
Overloaded with spam? With MSN 8, you can filter it out
http://join.msn.com/?page=features/junkmail&pgmarket=en-gb&XAPID=32&DI=1059
_______________________________________________
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.