Tim Bunce <Tim.Bunce@xxxxxxxxx> 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
