On 18 Jul 2007, at 20:26, Brandon Black wrote:
Well, I've tracked this down a little bit further now. I had poorly
assumed $dbh->{AutoCommit} would statically remain at whatever value
it was set to (or defaulted to) at DBI->connect time. As it turns
out, $dbh->begin_work turns off the $dbh->{AutoCommit} value, which is
what's causing the confusion.
We noticed this recently as well. Probably should have provided more
hints in my original mail :(
from DBI.pm:
sub begin_work {
my $dbh = shift;
return $dbh->set_err(1, "Already in a transaction")
unless $dbh->FETCH('AutoCommit');
$dbh->STORE('AutoCommit', 0); # will croak if driver doesn't support it
$dbh->STORE('BegunWork', 1); # trigger post commit/rollback action
return 1;
}
I'm wondering why DBI turns off autocommit rather than issuing a BEGIN
WORK statement - but I guess that's for the DBI list. It appears to be
so as to provide consistent behaviour/interface at the DBI level. We
were thrown off for a while because the
DBIx::Class::Storage::Statistics logging shows a 'BEGIN WORK'. Both DBI
and D::C::S::S document the behaivour, but it is just counter-intuitive
enough that it's easy to overlook.
Thanks for the speedy response,
Richard
_______________________________________________
List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
Wiki: http://dbix-class.shadowcatsystems.co.uk/
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
