• 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: Displaying Primary Keys
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Displaying Primary Keys


  • Subject: Re: Displaying Primary Keys
  • From: Drew Thoeni <email@hidden>
  • Date: Fri, 26 Dec 2003 15:48:16 -0500

Chuck (and others),

Your answers have proved very helpful. To more clearly state this, I'm not using the primary key as a piece of real data. It is, for nearly all purposes, meaningless. However, for administrative purposes, being the unique identifier of a row, the primary key creates its own meaning. For example, code tables that support the other tables. My PaymentMethodCode table, which has a short description of the payment types also, of course, has a primary key which, in this case, is paymentMethodCodeId. On administrative pages, it is helpful to identify these by their primary key and description (e.g. 10, Visa Credit Card).

For users, (and only for admin purposes) it is handy to have the primary key display to ensure the administrator is dealing with the right John Johnson. (e.g. 342568, John Johnson).

So, speaking from a relational table point of view (where I have more experience than WO), I agree with both schools. Nearly always I make the PK meaningless. It is handy to know that WO does not require that PKs not be part of the class.

Regards,

Drew

On Dec 26, 2003, at 2:47 PM, Chuck Hill wrote:

Drew,

There is no need to exclude a primary key from the class in order to have
EOF manage the relations. EOF simply removes the need to manage these
yourself.


There are two schools of thought on this, one is wrong ;-) and the other
maintains that primary key values should be meaningless. As meaningless
values, there is never any need nor use to display them in the UI. Thus,
the should not be included in the public (class) attributes in the EOModel.


If your userID is what the user types when they login, then it should *not*
be the PK. Add another column to serve as the key. This way if a userID
ever needs to be changed (e.g. for a legal name change, marriage, whatever)
then the update can be made to the information (what the user types)
without affecting the validity of the relationships. A rose by any other
name...


Chuck


At 08:54 AM 26/12/2003 -0500, Drew Thoeni wrote:
public void newbieProblem() {
I read (and have found) that if I want to properly used object
references between enterprise objects that I must not include the
primary key in the class (i.e., I click the diamond off in EO Modeler).
However, there are times I want to display the primary key. For
example, in administration pages, I like to display the userID. Or when
editing code tables, the primary key would be useful to display.
}


public Answer newbieQuestion() {
What is the proper way to do this? Any references out there you suggest.
}
_______________________________________________
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.


--

Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
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: Displaying Primary Keys
      • From: Chuck Hill <email@hidden>
References: 
 >Re: Displaying Primary Keys (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: Displaying Primary Keys
  • Next by Date: Re: Displaying Primary Keys
  • Previous by thread: Re: Displaying Primary Keys
  • Next by thread: Re: Displaying Primary Keys
  • Index(es):
    • Date
    • Thread