[Dbix-class] Recovering from a failed transaction ?

[Richard Robinson]

On Wed, Aug 08, 2007 at 01:16:19PM +0100, Matt S Trout wrote:
> On Wed, Aug 08, 2007 at 12:10:56PM +0100, Richard Robinson wrote:
> > 
> > I'm playing around with transactions, to get a feel for how they go. So I
> > have a little block of deletes and updates, called with
> > 
> > eval { $schema->txn_do($coderef); };
> > 
> > all very much as per the DBIx::Class::Storage doc. Run it with DBIC_TRACE
> > and I can see it go "BEGIN WORK ...<statements> ... COMMIT" (this is mySql),
> > or write a deliberate error and I see "ROLLBACK", just as I was hoping, all
> > very nice; until I go back to the calling page (it's a Catalyst app) and try
> > it again, when it doesn't seem to do the transaction thing any more - the
> > statements are issued bare, without the surrounding BEGIN WORK / ROLLBACK.
> > And they run up to the failing one, and duly leave things in a mess - once a
> > transaction's failed, they seem to be left disabled . Is this the expected
> > behaviour, is there something obvious that my deal_with_failed_transaction()
> > should be doing to bring them back to life ?  Or is this an artefact of
> > (a different) stupidity in my code ?
> 
> Did you set AutoCommit to 0 in your Cat config? If so, remove that, DBIC
> will default it to 1 which is usually what you want for txn_do

No, I saw that bit in the docs. And I've just checked, it is set to 1.

In the config. I've just spent 10 minutes looking for a way to query it at
runtime. Schema->storage->connect_info looked like a possibility, but
doesn't seem to.

-- 
Richard Robinson
"The whole plan hinged upon the natural curiosity of potatoes" - S. Lem