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

[Drew Taylor]

I'm in the situation where I have a bunch of legacy code which has
it's own database handle where AutoCommit=0, and a bunch of new code
which uses DBIC where AutoCommit=1. My task is to allow the use of the
new code with the old code. The legacy code manually starts and
commits transactions, so I'm going to have to deal with that. The
long-term goal is to move everything over to DBIC and then I can go
back to the standard DBIC idioms. The one thing I have to eliminate is
the possibility of having two database handles in use for any given
web request. There be dragons, and I have the (accidental) scars to
prove it. I'm lucky in that I have a comprehensive test suite for the
new DBIC code, so I'll know when I break things. :-)

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.

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.

Any thoughts from the DBIC gurus would be very welcome.

Thanks,
Drew
-- 
----------------------------------------------------------------
 Drew Taylor                 *  Web development & consulting
 Email: drew at drewtaylor.com  *  Site implementation & hosting
 Web  : www.drewtaylor.com   *  perl/mod_perl/DBI/mysql/postgres
 ----------------------------------------------------------------