In his announcement for DBD::Ingres-0.51 Henrik says:
The DBI docs state that swtiching the value of $dbh->{AutoCommit} from off to on should cause a $dbh->commit to be called, but setting $dbh->{ing_rollback} to on will cause a $dbh->rollback to be called instead.
This is mainly usefull in situations where you normally have $dbh->{AutoCommit}=1 and only in some subroutines change it to $dbh->{AutoCommit}=0 using local $dbh->{AutoCommit}=0; to get it reverted to normal use no matter how you leave the subroutine. In these cases it seems much more sensible to rollback any uncommited transactions on resetting AutCommit than to have them commited.
That seems like a very valid point to me. Commits should always be explicit not implicit. As it stands now this is very unsafe:
$dbh->{RaiseError} = 1; eval { local $dbh->{AutoCommit} = 0; ... } What to others think of this issue? (Please ignoring for the moment any backwards compatibility issues with changing this and focus on the principle.)
I have no particular problems with this.
On the other hand, if you say that (explicit commits; otherwise rollback), don't you need to define what happens on disconnect when there's an open transaction (and hence AutoCommit is off)? At the moment, that is 'implementation defined'.
Would you have a standard DBI attribute such as RollbackOnSetAutoCommit, with default value 1 (new) and available alternative 0 (old).
--
Jonathan Leffler ([EMAIL PROTECTED], [EMAIL PROTECTED]) #include <disclaimer.h>
Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/
