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

Adam Sjøgren asjo at koldfront.dk
Sat Nov 3 08:52:33 GMT 2007


On Fri, 2 Nov 2007 16:10:11 -0500, Brandon wrote:

> So long as your code is reasonably linear and only normally performs
> one transaction per request, perhaps.

(Sure, I just wanted to be sure I had not misunderstood the granularity
of the connection sharing).

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

When some of those things are overlapping, it becomes an ever-growing
problem, yup (but not between different "users" of the same connection).

I certainly agree - I'm not saying it is/was perfect, or even good, just
that some of the effects are appealing to me, and of course I'd like the
best of both worlds.

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

That sounds cool - I guess it also is way more configurable than what
people are used to today (the few using AutoCommit=0 getting "you forgot
to think about transactions"-feedback early, and the majority using
AutoCommit=1, who are less forgetful programmers :-))


  Best regards,

    Adam

-- 
 "I'm not sure it never causes any harm to all users."        Adam Sjøgren
                                                         asjo at koldfront.dk



More information about the DBIx-Class mailing list