Django default transaction behaviour

[Greg Kempe]

Hello,

Django's default handling of database transactions (ATOMIC_REQUEST=False) surprised me and I was hoping to understand the motivation behind it, and perhaps offer the suggestion that ATOMIC_REQUEST should be True by default.

Non-atomic requests as a default violates, in my view, the principle of least surprise. It means that if I have a new out-of-the-box Django app with relationships between models and, during a request, a model is created/updated and the creation/update of a related model fails, then I'm left with a database that's in an inconsistent state. The first object has been created, but the related one failed. My tests show this is true, but perhaps I'm missing something?

As a default experience for new users this seems like a bad idea and a poor experience. I like that Django provides granular control over this behaviour, but I feel for first-time (and most) users, atomic requests are a far simpler way to reason about your application.

I'd like to hear what the motivation for non-atomic requests by default are. The docs [1] state that:

"While the simplicity of this transaction model is appealing, it also makes it inefficient when traffic increases. Opening a transaction for every view has some overhead. The impact on performance depends on the query patterns of your application and on how well your database handles locking."

These days most databases are highly optimised for running multiple concurrent transactions. They're a critical part of ACID and building applications that behave predictably. By far the bulk of Django users are never going to be running websites so large that they need to be optimising at this level. That path should be available for users with very large sites, but a good choice of defaults can save many new (and not so new) users from surprises.

Thanks,

Greg

[1] https://docs.djangoproject.com/en/1.8/topics/db/transactions/