• 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: Denis Stanton <email@hidden>
  • Date: Tue, 29 Jul 2003 11:40:27 +1200

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.

  • Follow-Ups:
    • Re: EO: Should I create primary keys?
      • From: Goodbye Bill <email@hidden>
  • Prev by Date: Re: Help - my project folder thinks it's a package
  • Next by Date: Re: EO: Should I create primary keys?
  • Previous by thread: Re: EO: Should I create primary keys?
  • Next by thread: Re: EO: Should I create primary keys?
  • Index(es):
    • Date
    • Thread