[Dbix-class] Problem with populate() and commits?
davidi at norchemlab.com
Fri May 15 23:44:51 GMT 2009
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.
More information about the DBIx-Class