Re: EO: Should I create primary keys?
Re: EO: Should I create primary keys?
- Subject: Re: EO: Should I create primary keys?
- From: Jonathan Rochkind <email@hidden>
- Date: Mon, 28 Jul 2003 11:56:32 -0500
At 05:46 AM 7/28/2003 -0400, Goodbye Bill wrote:
QUESTION:
Should I create assign/create my primary keys myself OR should I [is it
possible to] rely entirely upon EO to do it?
I'd let EOF do it, if: you have no reason to do want to do it yourself,
and; it's a situaton where EOF is capable of doing it itself. (Which
usually it is).
The important thing is not to let the _db_ do it. With an 'autonumber'
field or something like that. EOF doesn't like that. But you can let EOF do
it, you can assign it yourself in code, either way works fine.
SCENARIO:
Wanting to be entirely object-driven, and not manipulate the database schema
directly, I have attempted to create all of my objects using ONLY EOModeler.
I didn't even know you could create objects using EOModeler, but okay, if
this works. The more typical scenario would be to create objects with a WO
application you write yourself, not with EOModeler. But wait, you say 'not
manipulate the db schema directly'---do you mean create all your db
_tables_ with EOModeler? That's a fine idea. The objects within those
tables, though... you can populate the tables however you want, no problem.
I wouldn't be scared of using the SQL interface of your choice to populate
the tables, at least for testing purposes. It does make things somewhat
simpler if you don't have any non-WO apps routinely inserting into the
tables, true.
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.
--Jonathan
_______________________________________________
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.