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

[Brandon Black]

On 11/2/07, Adam Sjøgren <asjo at koldfront.dk> wrote:
> 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?
>

So long as your code is reasonably linear and only normally performs
one transaction per request, perhaps.  In a complex app, all in one
request you might commit session state updates, user account updates,
site-wide statistics updates, and all sorts of other little side
things, in addition to one or more genuine updates to the core tables
underlying your model.

If you have database code wrapped in custom model methods that call
other custom model methods, like
"$c->model('Foo')->update_user_stats();", which somewhere in the
middle of its own transaction, also calls
"$self->source->schema->resultset('Bar')->update_site_stats();", which
has its own sub-txn (or at least perhaps it should), things get hairy.
 The more your DBIC code gets sprinkled around at various layers of
abstraction, the harder it gets to defend against sloppy coding wrt to
transactions.

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

We could make the policy thing have lots of sub-options.  One of them
could be to trigger on raw DBI/SQL access (with either a warning or an
exception).

I would imagine an interface like:

$schema_class_or_obj->coding_policy(
        require_autocommit => 'fatal', # or warn
        require_txns => 'fatal',
        require_txns_type => 'strict', # or heuristic
        disallow_raw_dbi => 'warn',
        disallow_search_literal => 'warn',
        disallow_cdbi_compat => 'fatal',
);

etc...
The schema obj can communicate the storage-related ones down to new
storage objects, and perhaps load another class/role into the usual
mix that overrides disallowed methods like search_literal, etc.

-- Brandon