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

[David Ihnen]

Peter Rabbitson wrote:
> David Ihnen wrote:
>   
>> 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.
>>     
> It is still not clear why do you want to run with autocommit off. What
> is the actual use-case?
>   
Because if you mutated the database state without a transaction it was 
The Wrong Thing To Do.

Because mutating without a transaction needs to effectively throws an 
exception - what you expected did not happen immediately and 
definitively.  (even if in this case it doesn't actually die/throw, it 
still very quickly does not do what you expected, which indicates an 
easy exception in basic functionality testing)

"It is good practice to throw exceptions early and often.  Not only does 
this help with code correctness, it helps reduce the likelihood of 
security vulnerabilities." (A programmer's introduction to C# 2.0 By 
Eric Gunnerson, Nick Wienholt, Anders Hejlsberg)

I can't put a gateway-permission layer on database mutation in my 
application if any line of code can mutate db state without going 
through the permissions layer.

I can't enforce my rule, You Must Use Transactions To Mutate, if 
autocommit is on - transactions are not then required for db state 
mutation.  And my application can't automatically roll inadvertent 
mutations back, they're already committed.

Given, the user could maliciously use txn_commit or whatever it is to 
get around the problem - but they won't learn that by example, and 
they're unlikely to do it accidentally.  Code quality is being improved 
by causing basic testing exceptions when accidentally attempting to 
mutate db state without using the transaction mechanism.

The use case is a safety against accidents to improve quality.

David