[Dbix-class] Problem with populate() and commits?

[David Ihnen]

Louis Erickson wrote:
> On Thu, 14 May 2009, Chris Cole wrote:
>
> <snip>
>
>   =

>> Why does it work fine when I have Autocommit 'on', but get the following
>> error with Autocommit 'off':
>>     =

>
> I'm surprised no one else has replied.
I must have missed the message.
>   This bit me too when I first =

> started with DBIC.  It seemed backwards to me at the time.
>   =

I started trying to modify it ot make it proper before reading the docs =

fully.

> DBIx::Class assumes autocommit is on, and works strangely or not at all i=
f =

> it is off.
>   =

Its actually programmed "if autocommit is off, do not issue begin, =

commit, or rollback instructions".  Which blew my mind and had me =

ranting wtfwtfwtf for a good hour.  I couldn't believe that it would be =

so very backwards in such well-executed and known code.
> If you must have it off, say, to share a db handle with older code that =

> requires it, you can usually finesse it to work but transactions will be =

> hard. The one time I found myself in that situation, I discovered opening =

> a second handle was easier.
>
> You'll be best off with DBIC to leave autocommit on and use DBIC's =

> transaction handling through txn_do instead.  It works well and handles =

> some things the raw DBI one won't.
I should tell you of my approach to this interesting problem, in which I =

solve the dilemma of 'was a previous modifier command issued' AND leave =

autocommit off.

I turned on autocommit initially becuase I wanted to enforce the =

application rules like this:

1. All modifications to the database shall occur in a dbic transaction.
2. If its not in a transaction, it didn't happen, and it will be rolled =

back with prejudice.

Imagine my frustration when I tried to impliment it and the system =

refused to issue transaction commands entirely!

Since as the documentation says, with autocommit off the library cannot =

trust that you didn't already do something, thus we cannot trust the DB =

transaction, I created a new method to call called =

'trust_dbic_transactions'.  I augmented a local copy of the DBIx::Class =

file in question that now operates as I wish it to.  (A Rollback is =

issued before every txn_do after called).  By setting this parameter I =

clearly state, if you say you trust, any modification done outside of a =

transaction IS WRONG, and gets rolled back, no questions asked.

So far its found a whole passel of bugs and deviations from application =

pattern that would not otherwise obvious - because you tell it to make a =

change and the change never happens!  I like this enforcement feature, =

and think my application is the better for it.

Maybe I should submit it as a patch to DBIx::Class - Sometimes for code =

quality reasons you actually DO want to trust dbic transactions, even =

though you've turned off autocommit.  (Because if autocommit is on, your =

application transaction layer loses control and a spurious modification =

sql can throw the db into a wrong state).  This is all part of the =

paradigm of making potential problems noisy.  Throw early, throw often, =

make it clear when something is not following the rules as soon as it is =

possible to tell.

David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20090515/844=
10cba/attachment.htm