Re: [GENERAL] undefined behaviour for sub-transactions?

Andrew Sullivan <[email protected]> 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


-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/[email protected]