Re: cdt glossary 0.1.1 [Transaction]

From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 20 Apr 2007 22:51:54 GMT
Message-ID: <eubWh.101559$aG1.76003@pd7urf3no>

Brian Selzer wrote:
> "paul c" <toledobythesea_at_oohay.ac> wrote in message
> news:383Wh.100591$DE1.26701_at_pd7urf2no...
>

>>Brian Selzer wrote:

> ..
> Codd (1970) defined consistency using the terms "state" and the phrase
> "instantaneous value." And later emphasized it: "It is important to note
> that consistency as defined above is a property of the instantaneous state
> of a data bank..."
> ...

I don't know why he used the adjective "instantaneous" to describe a value. Perhaps he chose to do that to appeal to the lingo of his expected audience. But I have no idea what an instantaneous value versus a non-instantaneous value could possibly be unless domains that may appear and disappear, or grow and shrink are allowed (which I wouldn't mind considering, but I don't think Codd had that in mind).

For database purposes, when Codd's information principle and the closed-world assumption are followed I also fail to see the need for a word like "state". It only encourages people to waste time imagining some difference between state and value when there is none.

>>
>>>I think that if a transaction contains more than one operation, then the 
>>>order in which each operation is evaluated is critical. 2 + 3 * 5 = 17, 
>>>not 25.
>>>
>>>After the following transaction,
>>>
>>>UPDATE r SET x = x + 5 WHERE k = 22,
>>>UPDATE r SET x = x * 4 WHERE k = 22
>>>...
>>
>>If all I wanted to do was to add 5 to x and then multiply by 4, I would 
>>expect my programming environment to give a single statement to the dbms, 
>>not two.
>>

>
>
> Perhaps, but the updates above are pretty simple, how would you deal with a
> transaction consisting of multple updates where the tuples targeted by each
> overlap?
> ...

I don't see how a transaction can involve more than one "update". As Jim Gray might have said, one can't marry two people at once.

>

>>>Is the result (x + 5) * 4 or (x * 4) + 5?  Or is it x * 4, which is what 
>>>D&D's multiple assignment would produce?
>>>...
>>
>>I'm not in favour of encouraging the complexity that multiple assignment 
>>requires a programmer to be aware of.  (I'm not even in favour of 
>>assignment to mutable variables.  I realize most programmers are used to 
>>them and expect them to be supported, but I don't care.)
>>

>
>
> I'm not sure what you mean by "mutable variables."
> ...

Maybe that's an unconventional term. I mean a variable that can be assigned to twice in whatever programming unit we define to constitute a transaction.

>

>>>Do you limit a transaction so that only one transformation can occur per 
>>>relation? Per tuple? Per attribute value?
>>>...
>>
>>Any concept of a database that has two different values at the same time 
>>is beyond me.
>>

>
>
> Who said anything about the database having two different values at the same
> time? The question involves a group of modifications to a database. The
> database wouldn't take on the new value until the entire transaction
> completed.
> ...

You did, when you said (above) that "one transformation" is a "limit".

>

>>>Should all constraints be checked after each operation?  Only some?  Or 
>>>should they all be deferred until the end?  I mention this because the 
>>>result of one operation may leave the database in an inconsistent state, 
>>>making any subsequent operations suspect.
>>>...
>>
>>Any dbms that allows a programmer to introduce an inconsistency should be 
>>recalled.
>>

>
>
> Transitory inconsistencies can occur, so long as they're resolved by the
> time that a transaction completes. A transaction executes in isolation, but
> the results of each operation in a transaction could be made visible to
> subsequent operations within the same transaction.
> ...

I'll repeat - any dbms that allows a programmer to introduce an inconsistency, transitory or otherwise, should be recalled. I'm sure that given the physical speed of the consumer machines that superceded the mainframes of his day, had they been available in 1969, Codd would not have suggested that the correction of inconsistencies could be postponed.

p Received on Fri Apr 20 2007 - 17:51:54 CDT