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

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.

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.


Cheers
Ari



-------------------------->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001   fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A