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

[Adam Sjøgren]

On Fri, 2 Nov 2007 14:43:12 -0500, Brandon wrote:

> 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.

In my use-case I do a rollback at the end of each request
(Catalyst-app), or the standalone script ends closing the connection -
that ought to take care of the "part of an unfinished transaction might
spill over into the next use of the connection", right?

It is easier once to set up the rollback-at-end than it is to remember
to wrap all updates/adds/removes in transactions every time - at least
that is my experience :-)

> 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).

Yeah. Mostly the mistakes that are important for me to catch are the
ones I make, and - lazy as I am - I like to get told about them as soon
as possible, preferable before anyone but me is affected by them.

(This goes for all the team members).

> 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.

That would be great - such a level would take away my reason to use
AutoCommit=0 completely.

(Except if I would mix in something using DBI directly instead of going
through DBIx::Class, but I shouldn't and most probably won't).


  Best regards,

    Adam

-- 
 "Although, in a sense, recognizing them as ancient           Adam Sjøgren
  might not necessarily be wrong, it's indeed useless."  asjo at koldfront.dk