On Aug 20, 2011, at 9:21 AM, Paul Hoadley wrote: > Hi Kevin, > > On 19/08/2011, at 9:33 PM, Kevin Hinkson wrote: > >> The general consensus seems to be don't use primary keys in the way I >> described, use another unique identifier/slug etc. But if one really, really >> has to; then the following are available: > > Actually, my advice was subtly different. The "best practice" which advises > you not to expose primary keys doesn't exist in a vacuum—there's an argument > behind it. If you think you've found a counter-argument, then why beat > yourself up by (a) not exposing the primary key as a class property and then > (b) using workarounds to subvert (a)? Just expose the primary key and move > on. Whether or not you've really found a decent counter-argument is a > separate question.
Yeah. Exposed PKs* are not likely to cause you immediate pain. Very likely in the future, but no real danger in the short haul. Avoid it if you can. Don't lose sleep if you can't. *HOWEVER If you have a compound PK that is made up of two or more Foreign Keys, then you must not expose them. This brings me to my favorite rant. Never, never, never expose Foreign Keys. Don't do it. Not ever! If you have compound PKs, then it's doubly true. If you do expose FKs you are in for a world of hurt. Sometimes problems will be subtle and hard to reproduce. Sometimes it will hose your DB and leave you with irrecoverable data. Seriously. Do. Not. Do. It. EVER! Dave _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
