Re: undefined behaviour for sub-transactions?

Re: undefined behaviour for sub-transactions?

am 15.11.2005 08:01:12 von Tyler MacDonald

Paul DuBois wrote:
> MySQL doesn't have sub-transactions (nested transactions). You can set
> savepoints within a transaction and roll back to a given savepoint and then
> continue the transaction from there.

Hopefully it will some day. :) I'm guessing other DBI drivers have
this behaviour too... when DBI talks to a driver, does it know if it
supports sub-transactions? For that matter, does it know if there is a
transaction already in progress?

I'm trying to support multiple database drivers at once. I have
methods that do small tasks (such as updating a table), and methods that
glue these small tasks together into big tasks (such as updating a table and
all of it's foreign keys). Whether it is a small task or a large task that
is being done, I would like the operation to be completely atomic.

I have each small task do it's own "begin_work/commit", and then
each large task wraps the whole thing in it's own "begin_work/commit". With
an engine that supports nested transactions, this works perfectly. With
MySQL, all of the SQL is still executed and comitted, but I get a warning on
the last commit, even it PrintWarn is set to 0.

I'd rather not have to investigate / guess what every single DBD
driver does and add change the behviour based on $dbh->{Driver}->{Name}.

Is there a way to ask DBI if it is already in a transaction? If it
knows this and I can get that information out of it, I could make this
package a lot more useable.

Thanks,
Tyler


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules@m .gmane.org