[Dbix-class] Legacy code integration - database handles + AutoCommit

[Rob Kinyon]

On Tue, Jul 28, 2009 at 07:37, Drew Taylor<taylor.andrew.j at gmail.com> wrote:
> So I have two questions:
>
> 1) Can I give my DBIC schema object a database handle instead of the
> schema procuring one for itself? And yes, this will be living in a
> world with Apache::DBI.

Yes. You'll have to delve a little into internals, but it's not hard.
Make sure you end up with a Storage::DBI::<whatever> object, not a
Storage::DBI object.

> 2) Given that all of DBIC's transaction idioms revolve around
> AutoCommit=1, what's the best approach to working in an AutoCommit=0
> world? My best thinking is that I have a separate method, say
> $schema->my_do_txn( $txn_sub ), which looks at the AutoCommit status
> and if true simply calls $schema->txn_do( $txn_sub ). However, if
> AutoCommit is off I was thinking to run $txn_sub and let the calling
> code handle errors. This approach feels messy, but it's the best I've
> come up with while we migrate code.

AutoCommit in DBI terms is not the same thing at all as AutoCommit in
DBIC terms.

Have you considered looking at savepoints? Most DBMSes (including
MySQL) support them now. That way, you can start a transaction at the
very beginning of the web request (outside of DBIC). You hand the $dbh
to DBIC and your old code. They each do their own thing. At the very
end of the web request, you either commit the whole thing or rollback
the whole thing.

Only thing you might have to do is create a facade around $dbh so that
the right syntax is generated for begin_work, commit, and rollback.
That's not very hard at all.

Rob