Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- Subject: Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- From: David Avendasora <email@hidden>
- Date: Fri, 16 Mar 2012 02:58:49 +0800
On Mar 16, 2012, at 1:54 AM, Kieran Kelleher wrote:
> OK, at the risk of chastisement, I disagree with David A and probably all of my other friends! :-)
Nah, I think you're take is probably the most common, and in some ways not entirely unreasonable. I've just been burned so many times by PKs and FKs being assigned meaning and then the business rule that the PK or FK represented changes and now I have to make it conform to the new business logic.
I've become a wee bit of a zealot about it. :-) So … read on if you dare…
> IMHO, if exists, it is real and probably for the lifecycle of your application, the PKs with never change and while some disagree, I am all for using "id" to sort or qualify a fetch if needed rather than invent some whole feature to avoid using it.
Ooooh! Hey! I can just look at the customer's "Phone Number" and tell by the area code what state they are in rather than invent some whole "State" feature! Wow look what I saved!
1 column in a database should represent just 1 thing. Just as you wouldn't use the phone number column to also define what state the customer's address is in, you shouldn't use the PK to represent any other concept. Sure, you _can_ sort by PK, but what you get is your EO's sorted by the PK. Is that actually useful? You don't necessarily get them sorted in the order in which they were inserted. My question is why *not* invent some whole feature? It's a database. One more indexed column is not going to bring your server to its knees.
On top of that, the assumption that the only thing that is ever going to read or write to your database is your one WebObjects app and all the data will go through EOF and have your business logic and validation applied to it is completely unrealistic for a majority of applications.
Haven't you never inserted data into your database with a SQL script? Scripts run by ERMigrations are necessarily going to generate PKs in the same way as EOF does. Script-based migrations themselves qualify as being run outside of "normal WebObjects usage" and they are *part of* a WebObjects application. God help you if you don't have FK constraints defined in your database.
PK's don't normally change, but by exposing them and giving them any other meaning you are almost guaranteeing that somebody at some point will want to change that meaning. "Hey, why is that customer at the top of the list?! They shouldn't be up there. Move them down."
Then there's the issue of less-than-competent developers. Several of the WO applications I've worked on have been around for 6+ years, and a couple for 10+. The number of developers that have touched them is astounding. Some developers are better than others. I hardly trust myself to not horribly corrupt the database (again), let alone trust that some noob developer 5 years from now isn't going to do something far stupider than me. No, really!
Just because you can't imagine how horribly badly a database can be abused doesn't mean that it doesn't happen, it just means that you think everyone is as competent and in as full control of the DB as you.
> If I was going to compromise, then I would simply make a field called UniqueID, and I would override willInsert and set that field to the same value as ERXGenericRecord.rawPrimaryKeyInTransaction(). yes, I *would* simply use EOF's PK as the value of my UniqueID field.
That's how I'd probably do it too, except I'd call it what its purpose is such as "REMOTE_ID" or "SORT_INDEX" or whatever. There's no problem with using the value of the PK initially if those values work for what you need. I'm just saying that you can't assume that your business logic needs are going to always and forever be in sync with the database's need to uniquely identify a row in a table.
Dave
—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™
—————————————————————————————
David Avendasora
Senior Software Abuser
Kaiten, Inc.
_______________________________________________
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