Re: undefined behaviour for sub-transactions?

Andrew Sullivan <ajs(at)crankycanuck(dot)ca> wrote:
> The inconvenience I'll grant, but the non-standard claim I think
> needs some justification. When the database encounters an error in a
> transaction, it is supposed to report an error. An error in a
> transaction causes the whole transaction to fail: that's what the
> atomicity rule of ACID means, I think. I actually am sort of
> unconvinced that SQLite's transactions are real ones -- I just did
> some playing around with it, and it seems that any error allows you
> to commit anyway. Certainly, MySQL's support of transactions is
> occasionally pretty dodgy, unless you use the strict mode.

Either way the end result is that some database drivers poison a
transaction if there's any error, others are selective about which errors
are fatal and which are not, and still others just don't care at all.

The end goal of DBIx::Transaction is to hide these differences from
the application so that transactions behave in a consistent way despite what
driver or driver options you're using, so on that note I've uploaded
DBIx-Transaction-0.002 to PAUSE, which will take the "lowest common
denominator", having any erronious query poison the entire transaction.

> But it's worth knowing that in Pg 8.1 and later, you can wrap such
> things in a subtransaction and get out of it that way.

Nifty! :)

Cheers,
Tyler