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