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 PROTECTED]

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 PROTECTED]
[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/ robertwalker1%40mac.com

This email sent to [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/chill% 40global-village.net

This email sent to [EMAIL PROTECTED]

--
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 protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to