python - 默认情况下 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 开发人员考虑了这类信息，并决定默认关闭自动提交（更容易错误处理和逆向）的好处超过了启用自动提交（增加并发性）的好处。