Re: EO: Should I create primary keys?
Re: EO: Should I create primary keys?
- Subject: Re: EO: Should I create primary keys?
- From: Goodbye Bill <email@hidden>
- Date: Mon, 28 Jul 2003 21:38:24 -0400
You're right... I had not found any way to let EOModeler make the
relationships. I was doing it all manually. I've taken your advice and
allowed EO to build them, however, now I am blessed with a ton of grade-A
confusion. ={
Would you mind lending a brain cell or three? How the heck do I use this
now?
Previously, I was creating the "Link" object and then setting a couple of
foreign keys manually. Now, the keys of the "Link" object are not exposed.
I'm assuming I'm supposed to add one object directly to the other and let EO
handle the association. But how?
Please help! ={
On 7/28/03 7:40 PM, "Denis Stanton" <email@hidden> wrote:
> I believe Bills problem here is he hasn't seen the place to define
> relationships is in EOModeler so he's trying to do all the work himself.
>
> Bill (or may I call you Goodbye? :-) ), you set up the relationships
> inside EOModeler with just a few clicks and then it does all the
> primary key / foreign key stuff for you. That's why the keys are not
> class properties - you don't (normally) have to do anything with them.
>
> Have another look at EOM. One of those circular icons along the top
> adds relationships.
>
> Denis
>
> On Tuesday, July 29, 2003, at 04:56 AM, Jonathan Rochkind wrote:
>
>>> PROBLEM:
>>> To create any relationship, one must specify the source and
>>> destination
>>> properties (essentially, the primary and foreign keys within the
>>> table).
>>> This means that the developer is forced to create the columns for the
>>> keys,
>>> assign the key attribute, etc., both while creating the table and
>>> while
>>> creating the relationship. This seems to violate the initial goal of
>>> EO,
>>> which is to extrapolate the database and the object model.
>>
>> I'm not following you. Why is this a problem? Yes, to create a
>> relationship in an EOModel, the developer must specify what columns
>> are used for fk/pk, and then use these columns in the relationship
>> definition. That's how you tell EOF how the relationship is defined,
>> true. Once you've done that, you can generally ignore those columns.
>> They shouldn't ordinarily be class properties. In your Java code, you
>> can (and generally should) deal only with the relationship, not with
>> the columns.
>>
>> I don't see why this is a problem, but, yes, this is the way EOF
>> works. Sure, EOF makes the db and the object model somewhat
>> independent. But they still need to be tied together _somewhere_. The
>> EOModel is the place they are tied together---the point of the EOModel
>> is basicaly to explain how the object model relates to the db. So of
>> course you need to refer to db columns in the EOModel.
>>
> Denis Stanton
> email@hidden
> Home: (09) 533 0391
> mobile: 021 1433622
> _______________________________________________
> 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.