Rationale for DB API 2.0 auto-commit off by default?

Question

PEP 249 -- Python Database API Specification v2.0 in the description of .commit() states:

Note that if the database supports an auto-commit feature, this must be initially off. An interface method may be provided to turn it back on.

What is the rationale behind that, given that most databases default to auto-commit on?

Answer 1

According to Discovering SQL:

The transaction model, as it is defined in the ANSI/ISO SQL Standard, utilizes the implicit start of a transaction, with an explicit COMMIT, in the case of the successful execution of all the logical units of the transaction, or an explicit ROLLBACK, when the noncommitted changes need to be rolled back (for example, when the program terminates abnormally); most RDBMSs follow this model.

I.e., the SQL standard states transactions should be explicitly committed or rolled-back.

The case for having explicit committing is best described by SQL-Transactions:

Some DBMS products, for example, SQL Server, MySQL/InnoDB, PostgreSQL and Pyrrho operate by default in the AUTOCOMMIT mode. This means that the result of every single SQL command will is automatically committed to the database, thus the effects/changes made to the database by the statement in question cannot be rolled back. So, in case of errors the application needs do reverse-operations for the logical unit of work, which may be impossible after operations of concurrent SQL-clients. Also in case of broken connections the database might be left in inconsistent state.

I.e., error handling and reversal of operations can be vastly simpler when using using explicit commits instead of auto-committing.

Also, from my observation of the users in the python mailing list, the consensus was that it is bad for auto-commit to be on by default.

One post states:

Auto commit is a bad thing and a pretty evil invention of ODBC. While it does make writing ODBC drivers simpler (ones which don't support transactions that is), it is potentially dangerous at times, e.g. take a crashing program: there is no way to recover from errors because the database has no way of knowing which data is valid and which is not. No commercial application handling "mission critical" (I love that term ;-) data would ever want to run in auto-commit mode.

Another post says:

ANY serious application MUST manage its own transactions, as otherwise you can't ever hope to control failure modes.

It is my impression that Python developers took this sort of information into consideration and decided the benefit of having auto-commit off by default (easier error handling and reversing) out weighed that of having auto-commit on (increased concurrency).