Paul is right, as far as I'm concerned. But, be really, really, really, really, really (really, really) sure you Need™ to expose it. Do everything you can to avoid it. If you only occasionally (in code) need to get an object by it's PK, then use the
EOUtilities.faultWithPrimaryKey EOUtilities.faultWithPrimaryKeyValue EOUtilities.objectWithPrimaryKey EOUtilities.faultWithPrimaryKeyValue methods. Be warned that the "faultWith" ones aren't safe if you don't already know that the PK exists in the DB, as those methods don't actually go to the DB and fetch the EO, they just create a fault for it. This means that if the PK doesn't actually exist in the DB, you'll get an exception at a later point when EOF tries to fully load the EO. The "objectWith" methods will throw an exception immediately, which is handy. If loading from a URL parameter, I'd _absolutely_ use the objectWithPrimaryKeyValue method. But I digress... If you are in control of the DB schema, create a second unique column (even populate it with the PK if you want). Every time I start depending upon PK values in code I end up regretting it. Most recently because we have several customers with their own instances of our App & DB. Now we want to merge the DBs and we've got a huge headache of conflicting PKs. Uhg. As Chuck once said (paraphrased), PKs (and therefore FKs) are not business data, They are an artifact of how a Relational DB implements relationships. Your application doesn't want some arbitrary row number from the table, it wants a specific row that has specific business meaning. Equating the two is a fallacy. Now, if you are working with a DB that someone else setup with meaningful PKs, well... you'll probably be okay. Maybe. :-) Dave On Aug 19, 2011, at 8:07 AM, Paul Hoadley wrote: > On 18/08/2011, at 11:05 PM, Kevin Hinkson wrote: > >> Since the best practice is to not make primary keys class properties, how do >> I then create a qualifier that is based on the primary key of an EO? > > My suggestion would be that you don't. Calling it a best practice isn't an > arbitrary designation—there's an argument behind it. And if you buy that > argument (whatever it is) for not making primary keys class properties, then > the same argument applies to creating qualifiers based on the primary key. > What does "not making a primary key a class property" mean if it doesn't mean > "making the primary key inaccessible to the class"? > > So if you've got a business or technical case for exposing the primary key, > just do it. It's only a best practice if you accept the argument behind > it—maybe you have a genuine exception. > > > -- > Paul. > > http://logicsquad.net/ > > > _______________________________________________ > 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/webobjects%40avendasora.com > > This email sent to [email protected] > > _______________________________________________ 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]
