[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