Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 03 Jun 2006 15:48:05 GMT
Message-ID: <Vaigg.231947$WI1.122572@pd7tw2no>

Bob Badour wrote:
> Mikito Harakiri wrote:
>

>> Robert Martin wrote:
>>
>>> Could you show me how you would construct a credit request packet from
>>> a customer record and send it to the credit service, and then process
>>> the response?  Just for the sake of argument we'll keep the packet
>>> simple.  The request packet is just a simple SSN encoded in BCD in five
>>> bytes.  The response is two bytes that contain a binary number whose
>>> value ranges from 0-999.  You send the request to port 884 of
>>> 124.132.4.23, and it will reply within 2 seconds.  If it doesn't reply
>>> within 2 seconds you need to retry.  After the third attempt, you need
>>> to declare an error in the current transaction and create a log file
>>> entry.  Given a valid reply, you set a flag in the customer record to
>>> ACCEPTED if the returned value is > 500, otherwise you set the flat to
>>> REJECTED.

>
>
> It looks like the self-aggrandizing ignorant directed the question to
> me. I added him to my twit-filter ages ago. The solution offered by
> Mikito is not what I would suggest and doesn't reflect the post to which
> Martin replied.
>
> Assuming:
> 1. The SSN is in ssn_var.
> 2. The customer relvar has a candidate key ssn.
> 3. The request relvar physically maps to a channel to 124.132.4.23:884
>
> I might propose:
>
> Repeat up to 3 times
> insert into request tuple( ssn_var ),
> wait seconds(2)
> until ( result = unwrap ( response )){}
> else log_and_abort("The error details");
>
> update customer
> set flag = case when result > 500 then ACCEPTED else REJECTED end case
> where ssn = ssn_var;

I like that one better but would like to also assume a requirement that we don't wait for two seconds if the channel happens to respond quicker.

I like it better because it emphasizes that part of the requirement is physical (ie., requiring time-outs or asynchronous evaluation) and I think this would mean that an OO language would have no advantage over a RM-based one.

It also illustrates that even when we think we are logically 'reading', at some physical level a 'write' is often entailed.

Seems useful to think about this in terms of a logical relation interface that is read-only. At one time I knew a table-based product, granted it wasn't relational, rather row-based where you could map memory and internal structures. A famous OS guy from the 1960's scoffed at the idea of having an operating system whose programming interfaces were limited to relations by asking how could one ever issue a START IO.   He went silent at the reply "INSERT".

p Received on Sat Jun 03 2006 - 10:48:05 CDT