• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EO: Should I create primary keys?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

References: 
 >EO: Should I create primary keys? (From: Goodbye Bill <email@hidden>)

  • Prev by Date: Saving entities problem
  • Next by Date: Re: EO: Object Collections?
  • Previous by thread: Re: EO: Should I create primary keys?
  • Next by thread: Re: EO: Should I create primary keys?
  • Index(es):
    • Date
    • Thread