Re: Qualifier With Primary Key
Re: Qualifier With Primary Key
- Subject: Re: Qualifier With Primary Key
- From: Jesse Tayler <email@hidden>
- Date: Thu, 18 Aug 2011 21:23:24 -0400
Plus 1.
If your business logic does not require using keys as logic then you likely want a generated unique id alongside your key.
There's a lot of reasons but some are that relational database keys have complicated, even obtuse logic that can vary between database and even versions.
As time goes by databases get merged, they suffer repairs or require import/export and unexpected relational alterations which can alter the logical handling of keys. So, leave that sort of thing to the database.
What is often substituted is a generated key - even if the generation is based on the primary key, you can alter the logic later to ensure uniqueness even in unexpected or even bizarre situations.
On Aug 18, 2011, at 9:09 PM, David Avendasora wrote:
> 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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden