At 4:04 PM -0500 10/22/07, Brandon Black wrote:
On 10/22/07, Darren Duncan <darren@xxxxxxxxxxxxxxxx> wrote:
Muldis DB also has separate start|commit|rollback_trans() methods
that the Perl application can invoke (but Muldis D stored routines
can't) whose purpose is to support wider-scope parent-most
transactions in the application where it isn't practical to put all
parts of it into a stored routine, such as because interaction with
non-database systems or users needs to be done between stages.
Based on my understanding, DBIx-Class' separate
txn_begin|commit|rollback() routines correspond to this, assuming
they aren't invoked by user code in a txn_do().
To summarize, I recommend for DBIx-Class an emphasis on txn_do() for
any situation where it would work, which includes executing just
single operations, and that autocommit=1 should be constant. An
autocommit=0 can be simulated by just having explicit
begin/commit/rollback where appropriate.
I think ideally we'd like to deprecate and/or eliminate
->txn_{begin,commit,rollback} as well, and basically stick users with
AutoCommit=>1 and txn_do. If we could find some concrete examples of
sane things that can't be done with just txn_do, that would be a good
reason to keep the others around, but I don't think such an example
exists (if you know of one, please speak up). txn_do closures and the
magic of $self->next::can covers just about everything I can think of.
Using just txn_do() for everything in DBIx-Class may very well be
feasible, more so than with using just call_proc() would be with
Muldis DB, so you may be able to do the deprecation you mentioned.
A key difference I see is that the Muldis DB framework presents an
isolated system (which is more effective for safety and portability).
A Perl application can call Muldis D routines, but Muldis D routines
can't call back out into the application environment (all closures
within Muldis DB are also, from the users viewpoint, written in
Muldis D rather than Perl).
As a result, since DBIx-Class' txn_do() can take an arbitrary Perl
closure as input, it can conceivably do more, since Perl closures
aren't so isolated.
In other words, I support your proposal.
-- Darren Duncan
|
