On Jan 11, 2007, at 4:20 PM, Robert Walker wrote:
Fabrice,The problem that you are having is related to primary key generation. There is no way for EOF to guarantee the generation of the same primary key values to two different entities. This is why modeling one-to-one relationships in EOF normally uses primary key propagation. What happens is that EOF would generate a new key for Entity A, then through propagation would assign that same key to the primary key of Entity B. The downside to this method is that you will always have a B for every A. This makes sense when you think about the object graph. Accessing B through the relationship in A needs to have a database row available when the fault representing B gets fired by accessing it.
And I suppose there is no way to "propagate" for example the primary key of B into A.bFid when you setBrelationship(A) ?
The simplest solution to this problem is to model your one-to-one relationship just like a one-to-many relationship. Then add code to your model classes to ensure that the "many side" of the relationship can only contain one item.Entity A idA fld1 fld2 ... fldn Entity B idB idA <<---- foreign key to A fld1 fld2 ... fldn Entity A <-------------->> Entity BConstrain the relationship A ------->> B to having only one B by using a cover method for managing that side of the relationship. Have the cover method remove any existing B objects before adding the new B object to the relationship. You can also add a cover method for reading B objects through A. Have the "getter" cover method return the first object in the A --------->> B relationship.This design pattern seems to be fairly typical in Object Relational Modeling environments that I've seen.
OKActually that's what I did finally while waiting for a "better" solution. If that's the best solution I can have, then I just have to keep it. Easy ! ;-)
Thanks a lot for the help :-) Regards Fabrice
On Jan 11, 2007, at 4:50 AM, Fabrice Pipart wrote:Hi all !I recently modeled my first one-to-one relationship in my EOModel (please dont laugh).And of course I had troubles ;-) I want this relationship to be optional and to be both sided. Here is how I did it : Entity A idA bFid bRelationship (source bFid, destination idB) Entity B idB aFid aRelationship (source aFid, destination idA) I want both relationships to be optional.There is no propagate primary key since I don't really understand how it works.The problem is :if I set A in B, I do have aFid set in DB but I don't have bFid set :-(I tried to understand the mechanisms of optional one-to-one relationships in the mailing list archives but I could not figure it out.Could someone please summarize what is a good way to model it? Regards Fabrice www.easyshadow.com International Corporate Consulting Palais de la Scala 1 avenue Henri Dunant Suite 1155 MC - 98000 Monaco Skype: fabrice.pipart Tel. +377 97 98 21 04 (direct) Fax. +377 97 70 88 07 _______________________________________________ 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/ robertwalker1%40mac.comThis email sent to [EMAIL PROTECTED]-- Robert Walker [EMAIL PROTECTED] _______________________________________________ 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/fabrice% 40easyshadow.comThis email sent to [EMAIL PROTECTED]
www.easyshadow.com International Corporate Consulting Palais de la Scala 1 avenue Henri Dunant Suite 1155 MC - 98000 Monaco Skype: fabrice.pipart Tel. +377 97 98 21 04 (direct) Fax. +377 97 70 88 07
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
