21 messages in com.mysql.lists.perlRe: undefined behaviour for sub-trans...| From | Sent On | Attachments |
|---|---|---|
| Tyler MacDonald | 14 Nov 2005 23:00 | |
| Jochen Wiedmann | 14 Nov 2005 23:16 | |
| Tyler MacDonald | 14 Nov 2005 23:41 | |
| Jochen Wiedmann | 14 Nov 2005 23:51 | |
| Tyler MacDonald | 15 Nov 2005 00:22 | |
| Jochen Wiedmann | 15 Nov 2005 00:32 | |
| Tyler MacDonald | 15 Nov 2005 00:45 | |
| Tyler MacDonald | 15 Nov 2005 00:57 | |
| Jochen Wiedmann | 15 Nov 2005 00:59 | |
| Tim Bunce | 15 Nov 2005 05:20 | |
| Tyler MacDonald | 29 Nov 2005 10:49 | |
| Tim Bunce | 29 Nov 2005 11:43 | |
| Andrew Sullivan | 30 Nov 2005 13:18 | |
| Tyler MacDonald | 30 Nov 2005 13:31 | |
| Jaime Casanova | 30 Nov 2005 13:44 | |
| Michael Fuhr | 30 Nov 2005 13:57 | |
| Tyler MacDonald | 30 Nov 2005 14:33 | |
| Tim Bunce | 30 Nov 2005 15:35 | |
| Jochen Wiedmann | 30 Nov 2005 21:04 | |
| Andrew Sullivan | 01 Dec 2005 04:45 | |
| Michael Fuhr | 01 Dec 2005 10:21 |
| Subject: | Re: undefined behaviour for sub-transactions? |
|---|---|
| From: | Tyler MacDonald (tyl...@yi.org) |
| Date: | 11/29/2005 10:49:39 AM |
| List: | com.mysql.lists.perl |
Tim Bunce <Tim....@pobox.com> wrote:
I'll guess that what you're really after is to be able to call begin_work again whilst an earlier begin_work is in effect and have the DBI keep a counter of how deeply nested the begin_work calls are. Then commit would decrement the counter and only commit at the outer most level.
If you really want that then it's straightforward to implement via a subclass.
This has been done. I'm only using it in two other packages so far, but both those and it's own unit tests seem to work well.
http://search.cpan.org/~CRAKRJACK/DBIx-Transaction-0.001/
I've got some ideas for enhancements too, but those are a bit more vauge. One of them is that there's differences in transaction behaviour across drivers when a query within a transaction fails. eg; under PostgreSQL, doing a SELECT on a table that doesn't exist poisons the rest of the transaction, whereas under MySQL and SQLite2 the transaction is allowed to continue.
There's gotta be some way to wrap this behaviour cleanly so that your application can expect the same behaviour regardless of the underlying database layer... but this leads to another question :-)
Are all database drivers expected to supply one method to execute a query? Eg; do "do", "execute", etc. all always funnel into one core method that returns success, error, or exception (if RaiseError) is turned on? Or if I wanted to create this functionality and expect it to work under multiple database drivers, should I override multiple methods?
Thanks, Tyler