Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- Subject: Re: ERXRestFetchSpecification defaultSortOrderings ordered by id (PK)
- From: Rich <email@hidden>
- Date: Fri, 16 Mar 2012 10:04:07 +1300
Wow, nice lot of comments to wake up to this morning (Yea a late start as I had to get the kids to school).
I do agree with all the points from everyone (how diplomatic is that!), and in 'Production' code I would never use the PK for anything - (probably ;o)
However this really is only a quick and dirty 'minimal' web-service for a proof-of-concept project, and will never be used in production as it only has basic core functionality. Any production one will require a complete database re-design.
My only quandary around all this is if the PK is 'so' precious' to EOF and should never be 'used' (Which I do see David A point), why is it returned by default in the ERRest data representation? - If it's not meant to be used for anything, surely it would be better not to return it at all hence forcing the developer to create an appropriate field if required.
On 16/03/2012, at 7:58 AM, David Avendasora wrote:
> 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