[Dbix-class] Recovering from a failed transaction ?

[Richard Robinson]

On Wed, Aug 08, 2007 at 01:57:06PM +0100, Richard Robinson wrote:
> 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...

(Duh. Data::Dump) and it remains 1 at runtime, throughout.

I take that's a "no, it's not the expected behaviour" ?

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