Re: [OT] Not everything goes well in Ruby land :-)

On Jan 7, 2008, at 7:02 PM, Aristedes Maniatis wrote:

>
> On 08/01/2008, at 10:13 AM, Mike Schrag wrote:
>
>>> If you expose any "developer private" information, users are  
>>> going to start to rely on it. Consider it UI. Preventing you from  
>>> making changes. I.e. Users could start bookmarking URLs with  
>>> primary keys in them.
>> But that's perfectly valid, right?  RESTful folks would say that  
>> your URL's ARE API ... Especially if you start exposing  
>> ActiveResource-style RESTful XML services, those are going to have  
>> to have SOME sort of ID's in them.  Like Chuck said, you could use  
>> some other candidate key, but if you have a sufficient non-OID  
>> candidate key that is going to be basically invariant and act in  
>> this capacity in your API, why not just make that your PK in WO in  
>> the first place?
>
> Another reason is that customers (that is the company we write code  
> for) will sometimes look at those exposed keys and start to ask for  
> them to become meaningful. "Those invoice numbers are great",  
> they'll say, "but if could you have all previous financial year  
> invoices have a letter appended to the end that would be great."
>
> So sometimes, what starts out at an invariant PK, changes in nature  
> as the project matures. Sure, invoice numbers are usually  
> invariant, numerical and monotonically increasing. Until Jo from  
> Accounts decides that they aren't. It can be easier to deal with  
> this if the exposed field isn't scattered across as FKs in a whole  
> bunch of related tables.

I think the original point was if you did not have any alternative.   
Certainly, if I had an invoice number or a catalog number or part  
number or whatever, I would use that instead of the PK.  But  
sometimes there just isn't anything else.


> Also, depending on the strategy for PK generation, sometimes they  
> are not monotonically increasing. That is, the requirements of  
> locking strategies, validation and database transactions means that  
> PKs could be skipped in the sequence. That can sometimes be  
> unacceptable for, say, invoice numbers.

Definitely, using generated unique identifiers for anything with  
human sensible meaning (e.g. invoice numbers) is a bad idea.  The  
skipped values almost always causes business problems.


Chuck

-- 

Practical WebObjects - for developers who want to increase their  
overall knowledge of WebObjects or who are trying to solve specific  
problems.
http://www.global-village.net/products/practical_webobjects