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