Re: cdt glossary 0.1.1 [Transaction]

On Apr 21, 8:57 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> paul c wrote:
> > Brian Selzer wrote:
>
> >> "paul c" <toledobythe..._at_oohay.ac> wrote in message
> >>news:383Wh.100591$DE1.26701_at_pd7urf2no...
>
> >>> Brian Selzer wrote:

> >>>> After the following transaction,
> >>>> UPDATE r SET x = x + 5 WHERE k = 22,
> >>>> UPDATE r SET x = x * 4 WHERE k = 22

[snip]

> I would expect the optimizer to simpify the above to:
>
> UPDATE r set x = x * 4 WHERE k = 22

and get a different result?

[snip]

> I find it fascinating that Selzer cannot get out of the begin
> transation/commit transaction mental box. If one has sufficient power
> available to describe every possible change as a single statement, one
> simply has no need for separate transaction boundaries.

It follows from the halting problem that there is no general algorithm that can analyse any other given algorithm to see what data it will read and modify without actually running that algorithm. It seems limiting indeed to say that you could reduce all update algorithms on data to a "single statement". However, it is true that you could record the changes as they are issued, and even to reduce all such changes into a single compressed overall delta. Most generally such changes can look rather like physical changes - even with respect to relational data which is itself grounded in FOL. This contrasts to the higher-level logical semantics in the update algorithm itself.

As an example, consider string-processing algorithms. Good programmers produce update algorithms that are incompressible. The resultant physical changes to the data can appear far more complex than the update algorithm itself.

Parenthesising an update algorithm with transaction boundaries can be regarded as a means to form a single "compound statement" out of the individual issued statements, or more generally the nested update algorithm.

Bob's idea that one has sufficient power available to describe every possible change as a single statement appears rather limiting, unless that sufficient power encompasses the ability to define arbitrary update algorithms.

The only reasonable alternative to explicit transaction boundaries that I've seen is to look for consistent cuts. However my understanding is that such approaches haven't been found to be practical.

[snip] Received on Sat Apr 21 2007 - 04:41:49 CEST