[Fixed]-Django: Pitfalls when setting AUTO_COMMIT = OFF for MySQL innoDB?

Quoting from the Django 1.9 docs here, with my bold emphasis added:

Django’s default behavior is to run in autocommit mode. Each query is immediately committed to the database, unless a transaction is active. […]

Django uses transactions or savepoints automatically to guarantee the integrity of ORM operations that require multiple queries, especially delete() and update() queries.

When autocommit is turned on and no transaction is active, each SQL query gets wrapped in its own transaction. In other words, not only does each such query start a transaction, but the transaction also gets automatically committed or rolled back, depending on whether the query succeeded. […]

To avoid this, you can deactivate the transaction management, but it isn’t recommended. […]

You can totally disable Django’s transaction management for a given database by setting AUTOCOMMIT to False in its configuration. If you do this, Django won’t enable autocommit, and won’t perform any commits. You’ll get the regular behavior of the underlying database library.

This requires you to commit explicitly every transaction, even those started by Django or by third-party libraries. Thus, this is best used in situations where you want to run your own transaction-controlling middleware or do something really strange.

In short, it looks like if you set autocommit to off, then you not only have to take care of the queries that your client code has initiated, but also the queries that are being executed internally by the framework, which you may not know about.

In addition, the framework is trying to guarantee the integrity of the system as it operates and it’ll be better to let it do its work for you rather than to fill your code with corner-cases to do the handling yourself. That will be error-prone in the best case, and a potential maintenance nightmare in the long-run.