Re: [GENERAL] undefined behaviour for sub-transactions?
Jaime Casanova <[email protected]>
| Newsgroups | gmane.comp.db.mysql.perl,gmane.comp.lang.perl.modules.dbi.general,gmane.comp.db.postgresql.general |
|---|---|
| Message-ID | <[email protected]> |
On 11/30/05, Tyler MacDonald <[email protected]> wrote: > 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. > that is a mis-conception... a transaction *must* be atomic (all or nothing)... the reason some databases act that bad is because they don't support savepoints, and because postgres does it doesn't need that awfulness... -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) -- MySQL Perl Mailing List For list archives: http://lists.mysql.com/perl To unsubscribe: http://lists.mysql.com/[email protected]