Re: EO: Not propagating key values...
Re: EO: Not propagating key values...
- Subject: Re: EO: Not propagating key values...
- From: Goodbye Bill <email@hidden>
- Date: Sun, 03 Aug 2003 03:48:23 -0400
Good info... Ints versus chars. I'll try that.
The logic behind the char(40) columns is compatibility. They contain GUIDs
to help make the tie-in with our existing Microsoft applications a bit
easier.
R/S
Bill
On 20030803 0325, "Art Isbell" <email@hidden> wrote:
> On Saturday, August 2, 2003, at 10:07 AM, Goodbye Bill wrote:
>
>> AAARRGH! NOTHING that I do will allow EO to propagate the IDs from a
>> parent
>> object to a child. I can understand setting the primary keys for
>> objects,
>> but I do NOT want to stuff foreign keys. How can I do this?
>>
>> My entities and relationships are set up as follows...
>>
>> Album
>> Songs
>> Song
>> Album
>>
>> Properties for the objects are as follows...
>>
>> ALBUM:
>> idPrivate (char(40))
>> dispName (char(255))
>>
>> SONG:
>> idPrivate (char(40))
>> idAlbum (char(40))
>> dispName (char(255))
>>
>> The "Songs" relationship is one-to-many and is basically...
>>
>> Album.idPrivate -> Song.idAlbum (inner join)
>>
>> The "Album" relationship is a one-to-one and looks as follows...
>>
>> Song.idAlbum -> Album.idPrivate (inner join)
>>
>> I have tried the following syntax...
>>
>> ATTEMPT #1:
>> oSong.setAlbum(oAlbum);
>>
>> ATTEMPT #2:
>> oAlbum.addObjectToPropertyWithKey(oSong, "Songs");
>>
>> The first attempt, above, causes an error saying that the "idAlbum"
>> property
>> cannot be null (which tells me it's not being supplied). The second
>> one
>> complains about not using a formatter.
>>
>> If I programmatically set the IDs manually, everything works fine.
>> How can
>> I NOT do this?
>
> You wouldn't normally have access to primary and foreign keys because
> they're not normally class properties (no diamond icon). I notice that
> these keys are char(40). EOF is much happier with meaningless integer
> keys. Is there some reason why your primary and foreign keys must be
> chars, not ints?
>
> They would need to be class properties if they have meaning. Semantic
> keys can cause problems because EOF doesn't allow their values to be
> updated whereas if keys were meaningless integers and these char(40)
> columns were just a regular columns, then these columns could be
> updated. So this may be at the root of the problems you're seeing.
>
> The second problem is that you didn't use the correct method to set
> the relationship property. Always use
> addObjectToBothSidesOfRelationshipWithKey(). Maybe this is the reason
> a foreign key wasn't being set.
> addObjectToBothSidesOfRelationshipWithKey() invokes setAlbum() and
> addObjectToPropertyWithKey(), so these methods must be defined, but you
> shouldn't use them directly.
>
> Without knowing the properties of the relationships in your eomodel,
> I'm just offering a couple of guesses to try.
>
> Aloha,
> Art
> _______________________________________________
> 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.
_______________________________________________
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.