On Thu, 1 Nov 2007, Brandon Black wrote:
> On 11/1/07, Louis Erickson <[EMAIL PROTECTED]> wrote:
> > I do have a question regarding txn_do, though, for I don't understand how
> > it can work properly with AutoCommit => 1.
<snip>
> > How does txn_do solve this? This is the part I don't understand. Perhaps
> > one of the experts here can explain it.
<snip>
> All of that aside, anyone who talks about "AutoCommit => 0" being a
> required for properly supporting multi-statement transactions with
> whatever appropriate level of transaction isolation is supported by
> the underlying DBMS is on the wrong track.
>
> You can have the same multi-statement transactions with the same
> guarantees of serialization with or without AutoCommit at the DBI
> level. At the DBI levels and below, all the way to your database,
> there is no difference between:
>
> $dbh->{AutoCommit} = 0;
> $dbh->do("INSERT ...");
> $dbh->do("DELETE ...");
> $dbh->commit;
>
> and:
>
> $dbh->{AutoCommit} = 1;
> $dbh->begin_work;
> $dbh->do("INSERT ...");
> $dbh->do("DELETE ...");
> $dbh->commit;
Ah-ha! There is a big thing in there that I didn't know about! That
little "begin_work" method is new to me, and serves a really important
purpose here. Using that makes real transactions possible, even with
AutoCommit on.
A critical thing that I'd completely missed. It's been in DBI since 2001,
and I had never managed to run in to it before.
> However, for the abstractions DBIC is trying to support, AutoCommit=>1
> is really the only way to go. AutoCommit=>0 would either require us
> to require all sql-generating code be in explicitly marked txns
> (marked by a begin_work-like call), which would suck for lots of
> existing modules out there, or if we didn't do so, would require us to
> somehow magically deal with ambiguously nested transaction contexts.
> AutoCommit=>1 doesn't suffer from these issues.
Sure, that makes sense. The inability to do the more complex, multi-step
transactions seemed like a glaring problem, and I was actually pretty sure
that folks of the caliber I've seen around here wouldn't have missed it,
but I didn't see the solution.
The explanations of why AutoCommit=>0 isn't going to mix well with DBIC
were already pretty well hashed out, actually. The only hole seemed to be
multi-step transactions, and that is possible. DBIC handles it, and I can
make it happen on my own. With that in place, I don't see any reason to
struggle with AutoCommit=>0 compatibility either.
> As far as the DBIC-level txn api goes, "txn_do($coderef,@args)"
> basically does something like the following pseudocode from the user
> perspective:
<snip>
> However, nobody's come up with any sane example of
> anything they'd want to do with those calls that can't be accomplished
> via txn_do(), which saves you working out all the gory details
> yourself and probably handles things better.
I'd figured most of that out from the code. I was all over it, debugging
the transaction depths and figuring out what was going on, trying to make
sure I wasn't doing something silly before I posted. Either I missed the
begin_work call, or it was in a helper function and I didn't realize it
was a native DBI call.
The only other reason I'm using AutoCommit=>0 is some other non-DBIC code,
but I can either open a separate DB connection for that, or use begin_work
myself in it. Or re-write it with DBIC, finally. I'll probably do the
latter, and then quit worrying about it. (Or the separate connection, as
that's very simple, and then a re-write next.)
Thank you *very* much for the clear reply! It completely answered my
question and resolves any concern I may have had.
--
Louis Erickson - [EMAIL PROTECTED] - http://www.rdwarf.com/~wwonko/
It was one of those perfect summer days -- the sun was shining, a
breeze was blowing, the birds were singing, and the lawn mower was
broken ...
-- James Dent
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
