DB API 2.0 自动提交默认关闭的理由是什么？

Question

PEP 249——Python 数据库 API 规范 v2.0在.commit()的描述中指出：

请注意，如果数据库支持自动提交功能，则必须首先关闭该功能。可以提供接口方法来将其重新打开。

鉴于大多数数据库默认为自动提交，其背后的理由是什么？

Answer 1

根据发现 SQL：

事务模型，如 ANSI/ISO SQL 标准中定义的那样，利用事务的隐式启动，在事务的所有逻辑单元成功执行的情况下，使用显式 COMMIT，或者显式 ROLLBACK，当未提交的更改需要回滚时（例如，当程序异常终止时）；大多数 RDBMS 都遵循此模型。

即，SQL 标准规定事务应该显式提交或回滚。

SQL-Transactions最好地描述了显式提交的情况：

某些 DBMS 产品，例如 SQL Server、MySQL/InnoDB、PostgreSQL 和 Pyrrho 默认情况下以 AUTOCOMMIT 模式运行。这意味着每个 SQL 命令的结果都会自动提交到数据库，因此相关语句对数据库所做的影响/更改无法回滚。因此，如果出现错误，应用程序需要对逻辑工作单元执行反向操作，这在并发 SQL 客户端操作之后可能是不可能的。此外，如果连接断开，数据库可能会处于不一致的状态。

即，当使用显式提交而不是自动提交时，错误处理和反转操作可以变得更加简单。

另外，根据我对 python 邮件列表中用户的观察，一致认为默认启用自动提交是不好的。

一篇帖子指出：

自动提交是一件坏事，也是 ODBC 的一个非常邪恶的发明。虽然它确实使编写 ODBC 驱动程序变得更简单（即不支持事务的驱动程序），但有时也存在潜在危险，例如程序崩溃：无法从错误中恢复，因为数据库无法知道哪个错误数据有效，哪些无效。处理“关键任务”（我喜欢这个术语；-）数据的商业应用程序都不会希望在自动提交模式下运行。

另一篇帖子说：

任何严肃的应用程序都必须管理自己的事务，否则您将永远无法控制故障模式。

我的印象是，Python 开发人员考虑了此类信息，并认为默认情况下关闭自动提交（更容易错误处理和逆转）的好处胜过打开自动提交（增加并发性）的好处。