[Dbix-class] Re: ROLLBACK seems to be skipped on 0.08

[Brandon Black]

On 11/2/07, Adam Sjøgren <adsj at novozymes.com> wrote:
> On Thu, 1 Nov 2007 21:38:25 -0500, Brandon wrote:
>
> > You can have the same multi-statement transactions with the same
> > guarantees of serialization with or without AutoCommit at the DBI
> > level.  At the DBI levels and below, all the way to your database,
> > there is no difference between:
>
> > $dbh->{AutoCommit} = 0;
> > $dbh->do("INSERT ...");
> > $dbh->do("DELETE ...");
> > $dbh->commit;
>
> > and:
>
> > $dbh->{AutoCommit} = 1;
> > $dbh->begin_work;
> > $dbh->do("INSERT ...");
> > $dbh->do("DELETE ...");
> > $dbh->commit;
>
> The thing I like about AutoCommit=0 is that if the lazy programmer
> writes some code that modifies the database without considering how much
> should be wrapped in a transaction (i.e. he does not ensure that a
> commit is there), it doesn't work as he expects.
>
> To me that is a nice way to ensure that I remember to consider
> transactions for all the parts of the code that modifies/adds stuff.
>
> Since txn_do arrived, I know I ought to use that for transactions, every
> time I need them, but with AutoCommit=1 I lose the automatic kick in the
> head if (when) I forget.
>
>

That cuts both ways though.  If a lazy programmer forgets to wrap a
txn in AutoCommit => 0 mode, it could easily just become the first
part of the next transaction that occurs on that connection in some
totally unrelated code (perhaps miliseconds later), which is even more
hidden and insidious.  The bottom line is that regardless of
AutoCommit mode, nothing can save you from team members accidentally
not putting things in transactions that should be (well, perhaps a
really well-written unit testing suite for your app that checks the
validity of all of the database interactions).

It would be interesting to discuss implementing some sort of "strict
transactions" policy-enforcing code that could enabled in DBIC, that
might try to enforce good txn behavior.  It might have levels of
enforcement like:

ultimate => throw a fatal exception if user code emits a modifying
statement (ins/upd/del) that isn't wrapped in a txn_do.  Of course,
txn_do is needless overhead for true one-statement transactions in
AutoCommit => 1 mode, but if you really wanted to be anal this would
be the option for you.

heuristic => throw a fatal exception if a single subroutine (based on
caller context) issues multiple modifying statements without enclosing
them in txn_do.  This lets people do true one-statement modifications
without txn_do in isolated methods, but tries to catch them doing
anything more complicated without it.

(Or also, support the above with just warnings rather than exceptions).

These would cost some performance, but they could also just be turned
on in development too.

Perhaps something for the 0.09 feature list?

-- Brandon