On Mon, 2004-01-12 at 10:26, Tim Bunce wrote:
> 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.)
>
> Tim.
I think commits should always be explicit. I go out of my way to ensure
that that is the behavior I get. Furher, I have never seen a well
written application the understood the scope of its transaction, that
used auto commit behavior, (and I'm not sure its possible to write one)
:-)
Lincoln
