Re: One-to-One Relationship
Re: One-to-One Relationship
- Subject: Re: One-to-One Relationship
- From: Chuck Hill <email@hidden>
- Date: Wed, 22 Mar 2006 18:39:53 -0800
On Mar 21, 2006, at 10:28 PM, Robert Walker wrote:
Louis,
One-to-one relationships are interesting beasts in EOF. It seems
to have something to do with EOF's primary key generation. Since a
one-to-one relationship connects the PK of one table to the PK of
another table you don't want EOF to try to generate keys for both
sides.
I don't think there is anything mysterious or interesting about to-
one relationships. You can keep the PK of the destination in the
source table as a FK and not have any problems at all. The problem
is when you try to have an optional PK-PK relationship. As the
source PK can't be null (or it would not be a good PK!), then the
relationship can't be optional. EOF will create "dummy fault EOs"
for you, objects full of nulls. For mandatory relationships, the
primary keys must be the same(aka equal). This is handled by
selecting Propogate Primary Key in the EOModel. When this is
selected, the destination object is created when the source (parent,
whatever) is inserted into an editing context. You do not create
this explicitly in code. If do create it, there will be two such
objects, and one will be full of nulls floating, lost in the editing
context.
Chuck
It is possible to set one side of the relationship to propagate
it's primary key to the other side. Doing so will tell EOF to
generate one PK and then propagate that key to the other object.
The effect of this is that both objects are always created (both
tables with have the same number of rows with PK matches for each
row), so you may end up with a lot of rows in one table, even if
you don't need them. This is probably fine as long as your tables
aren't huge and you are using a reasonably modern RDBMS.
One workaround for this is to use a one-to-many relationship and
add validation logic to ensure that only one object can exist on
the many side. Now you can treat this like a one-to-one without
creating unused rows on one side. Additionally you can add a
"cover" method that returns the first (and only) object from the
many side.
--
Robert Walker
email@hidden
There are 10 types of people in the world, those who count in
binary, and those who don't.
On Mar 22, 2006, at 1:06 AM, Louis Demers wrote:
Hi,
-----------
Background:
I have two objects setup tied by a bidirectional one-to-one
optional relationships. both classes have acessors for the
relationships in their classe.
TelehoneLine.java contains
public class TelephoneLine extends EOGenericRecord {
...
public Contact employee() {
return (Contact)storedValueForKey("employee");
}
public void setEmployee(Contact value) {
takeStoredValueForKey(value, "employee");
}
...
}
Contact.java contains
public class Contact extends EOGenericRecord {
...
public TelephoneLine telephoneLine() {
return (TelephoneLine)storedValueForKey("telephoneLine");
}
public void setTelephoneLine(TelephoneLine value) {
takeStoredValueForKey(value, "telephoneLine");
}
...
}
Both one-to-one relationships (employee and telephoneLine) are
defined
optional, nullify, DO NOT own destinations. and their foreign keys
allow zeros.
--------
Problem:
When I use "addObjectToBothSidesOfRelationshipWithKey"
aTelephoneLine.addObjectToBothSidesOfRelationshipWithKey
(selectedEmployee,"employee");
only half of the relationships get updated. I crafted the
following code that does update both sides
-----------
Workaround:
if (aTelephoneLine.employee() != null ){
aTelephoneLine.employee().setTelephoneLine(null);
}
aTelephoneLine.setEmployee(selectedEmployee);
if (selectedEmployee != null ){
selectedEmployee.setTelephoneLine(aTelephoneLine);
}
but I don't undestand why
"addObjectToBothSidesOfRelationshipWithKey" doesnt' work and
suspect I screwed up somewhere.
--
Louis Demers ing.
2447 Bellevue
St-Romuald, Quebec
Canada G6W 2T8
418 839-9266 (res.)
418 953-6204 (cell.)
email@hidden
email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Coming in 2006 - an introduction to web applications using WebObjects
and Xcode http://www.global-village.net/wointro
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden