Yes, it is possible to create one-to-one relationships, joined on the
primary keys. One side of the relationship will need "Propagates
primary key," as has been mentioned.
I just wanted to add one caveat to this configuration: The
relationship will always be 1-to-1 and will never be 1-to-0. In other
words if you created an instance of the entity on the side
propagating the key, you will get an instance of the other side of
the relationship. This will happen even if no fields are set on the
other side. This means that if any attributes (other than the PK) on
the other side of the relationship are set to required, neither
object will save.
Also if you attempt to create a new instance on other other side (not
propagating the key) you will also have problems saving.
As far as I recall this is the experience that I've had when
attempting to do this. Because of these complications I now opt for
the more flexible one-to-one style by setting it up in the model as a
one-to-many relationship. Then force the many-side to allow only one
or zero related rows though validation logic.
This also makes me think of the Ruby on Rails associations mechanism
for creating one-to-one relationships:
One-to-one
Master:
has_one :detail
Detail:
belongs_to :master
as opposed to the one to many setup...
One-to-many
Master:
has_many :details
Detail:
belongs_to :master
It seems to me that adding something along this line to EOF would be
very useful, and not particularly difficult. I don't mean in the
syntax above, but rather having a "built-in" way to constrain the
many-side to allow only one. Come to think of it: Core Data supports
this in its relationship configuration. It even goes a step further
by allowing you to specified the number of related objects allowed.
On Apr 2, 2008, at 1:48 PM, Jacky Gagnon wrote:
Hi Jeff,
I've decided to fully EOize my app to replace my current use of
flat files, mainly to better deal with concurrency issues. In
creating my analogous tables, I found that there's no way to
specify a "1 to 1" relationship between tables using the Entity
Modeler tool. Is there a specific reason for this? Or is it just
figured that you might as well make it one to many anyway even if
it is just one to one?
You can specify «1 to 1» relationship with Entity Modeler.
If the destination cannot be null, use the same id in the two tables.
-In Properties > Basic select : the cardinality «To One», your
destination, and add your primary keys.
-In Properties > Advanced select : for the source object, check
Propagates primary key and Owns Destination (if the destination
object cannot exist without an owner).
Good luck!
Jacky
If you're wondering why I want to do this, it's to hopefully
reduce conflicts of multiple people updating the same record in a
table. Is that generally a good reason to split 1 to 1 data into
two tables?
Thanks,
Jeff
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/jgagnon%
40druide.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/robert.walker%
40bennettig.com
This 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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
