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: [hidden email]  *  Site implementation & hosting
 Web  : www.drewtaylor.com   *  perl/mod_perl/DBI/mysql/postgres
 ----------------------------------------------------------------

_______________________________________________
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/dbix-class@...

[Rob Kinyon]

On Tue, Jul 28, 2009 at 07:37, Drew Taylor<[hidden email]> 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

_______________________________________________
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/dbix-class@...