数据库事务

Django 默认的事务行为

Django 默认的事务行为是自动提交。除非事务正在执行，每个查询将会马上自动提交到数据库， 详见下文。

Django 自动使用事务或还原点，以确保需多次查询的 ORM 操作的一致性，特别是 delete() 和 update() 操作。

由于性能原因，Django 的 TestCase 类同样将每个测试用事务封装起来。

显式控制事务

Django 提供了一个 API 控制数据库事务。

atomic(using=None, savepoint=True, durable=False)[源代码]

原子性是数据库事务的定义属性。 atomic 允许创建代码块来保证数据库的原子性。如果代码块成功创建，这个变动会提交到数据库。如果有异常，变动会回滚。

atomic 块可以嵌套。在这个例子里，当内部块成功完成时，如果在稍后外部块里引发了异常，则仍可回滚到最初效果。

It is sometimes useful to ensure an atomic block is always the outermost atomic block, ensuring that any database changes are committed when the block is exited without errors. This is known as durability and can be achieved by setting durable=True. If the atomic block is nested within another it raises a RuntimeError.

atomic 既可用作 decorator:: ：

from django.db import transaction

@transaction.atomic
def viewfunc(request):
    # This code executes inside a transaction.
    do_stuff()

也可用作 context manager:: ：

from django.db import transaction

def viewfunc(request):
    # This code executes in autocommit mode (Django's default).
    do_stuff()

    with transaction.atomic():
        # This code executes inside a transaction.
        do_more_stuff()

在 try/except 块中使用装饰器 atomic 来允许自然处理完整性错误：

from django.db import IntegrityError, transaction

@transaction.atomic
def viewfunc(request):
    create_parent()

    try:
        with transaction.atomic():
            generate_relationships()
    except IntegrityError:
        handle_exception()

    add_children()

在这个例子里，虽然 generate_relationships() 会通过破坏完整性约束导致数据库错误，但你可以 add_children() 中执行查找，来自 create_parent() 的变化也会在这里，并且绑定到相同的事务。注意，任何试图在 generate_relationships() 中执行的操作在 handle_exception() 被调用的时候也会安全的回滚，因此异常处理也会在必要的时候在数据库上操作。

要避免在 atomic 内部捕捉异常！

当存在 atomic 块时， Django 查看它是否正常退出或存在异常来决定是提交还是正常回滚。如果你在 atomic 内部捕捉并且处理异常，你可以对 Django 隐藏问题代码。这会导致一些意外的行为。

这主要是 DatabaseError 和它的子类的一个问题（比如 IntegrityError ）。出现这样的错误之后，事务会奔溃，并且 Django 将在 atomic 块的末尾执行回滚。如果你打算在回滚发生的时候运行数据库查询，Django 将引发 TransactionManagementError 错误。当 ORM 相关的信号处理程序引发异常时，你也可能遇到这个问题。

捕捉数据库错误的正确的方法是像上方所示那样围绕 atomic 块。如有需要，为此目的可以添加额外的 atomic 块。这个模式有别的优势：如果异常发生，它会明确界定哪些操作将回滚。

如果捕获由原始SQL查询引发的异常，那么Django的行为是未指定的，并且依赖于数据库。

当回滚事务时，你可能需要手工恢复模型状态。

当事务回滚时，模型字段的值不会被恢复。除非你手工恢复初始的字段值，否则这会导致模型状态不一致。

例如，给定带有 active 字段的 MyModel 模型，如果在事务中更新 active 到 True 失败，那么这个片段确保最后的 if obj.active 检查使用正确的值：

from django.db import DatabaseError, transaction

obj = MyModel(active=False)
obj.active = True
try:
    with transaction.atomic():
        obj.save()
except DatabaseError:
    obj.active = False

if obj.active:
    ...

为了保证原子性，atomic 禁用了一些API。在 atomic 块中试图提交、回滚或改变数据库连接的自动提交状态将引发异常。

atomic 带有 using 参数，这个参数是数据库名字。如果这个参数没有提供，Django 会使用默认数据库。

在后台，Django 的事务管理代码：

• 当进入最外面的 atomic 块时打开事务；
• 当进入 atomic 块内部时创建一个保存点；
• 从块内部退出时释放或回滚保存点；
• 离开块的最外层时提交或回滚事务。

你可以通过设置 savepoint 参数为 False 来为内部块禁用保存点的创建。如果发生异常，Django将在退出带有保存点的第一个父块（如果有的话）时执行回滚，否则退出最外面的块。外部事物仍保证了原子性。仅当保存点开销明显时，才应使用此选项。它的缺点是破坏了上述错误处理。

当自动提交关闭时，可以使用 atomic 。它将只使用保存点，即使对于最外面的块也是如此。

保存点

正确处理保存点（即嵌套了 atomic() 块）。也就是说，注册在保存点后的 on_commit()  的调用（嵌套在 atomic() 块）将在外部事务被提交之后调用，但如果在事务期间回滚到保存点或任何之前的保存点之前，则不会调用：

with transaction.atomic():  # Outer atomic, start a new transaction
    transaction.on_commit(foo)

    with transaction.atomic():  # Inner atomic block, create a savepoint
        transaction.on_commit(bar)

# foo() and then bar() will be called when leaving the outermost block

另一方面，当保存点回滚时（因引发异常），内部调用不会被调用：

with transaction.atomic():  # Outer atomic, start a new transaction
    transaction.on_commit(foo)

    try:
        with transaction.atomic():  # Inner atomic block, create a savepoint
            transaction.on_commit(bar)
            raise SomeError()  # Raising an exception - abort the savepoint
    except SomeError:
        pass

# foo() will be called, but not bar()

执行顺序

事务提交后的的回调函数执行顺序与当初注册时的顺序一致。

异常处理

如果一个带有给定事务的 on-commit 函数引发了未捕获的异常，那么同一个事务里的后续注册函数不会被运行。这与你在没有 on_commit() 的情况下顺序执行函数的行为是一样的。

执行时间

你的回调会在成功提交之后执行，因此回调里的错误引发事务回滚。它们在事务成功时有条件的执行，但它们不是事务的一部分。对于有预期的用例（邮件提醒，Celery 任务等），这样应该没啥问题。如果它不是这样的用例（如果你的后续操作很关键，以至于它的错误意味着事务失败），那么你可能不需要使用 on_commit() 钩子。相反，你可能需要两阶段提交——比如两阶段提交协议支持（ psycopg Two-Phase Commit protocol support ）和在 Python DB-API 里说明的可选两阶段提交扩展（ optional Two-Phase Commit Extensions in the Python DB-API specification ） 。

直到在提交后的连接上恢复自动提交，调用才会运行。（因为否则在回调中完成的任何查询都会打开一个隐式事务，防止连接返回自动提交模式）

当在自动提交模式并且在 atomic() 块外时，函数会立即自动运行，而不会提交。

on-commit 函数仅适用于自动提交模式（ autocommit mode ），并且 atomic() （或 ATOMIC_REQUESTS ）事务API。当禁用自动提交并且当前不在原子块中时，调用 on_commit() 将导致错误。

在测试中使用

Django's TestCase class wraps each test in a transaction and rolls back that transaction after each test, in order to provide test isolation. This means that no transaction is ever actually committed, thus your on_commit() callbacks will never be run.

You can overcome this limitation by using TestCase.captureOnCommitCallbacks(). This captures your on_commit() callbacks in a list, allowing you to make assertions on them, or emulate the transaction committing by calling them.

Another way to overcome the limitation is to use TransactionTestCase instead of TestCase. This will mean your transactions are committed, and the callbacks will run. However TransactionTestCase flushes the database between tests, which is significantly slower than TestCase's isolation.

为什么没有事务回滚钩子？

事务回滚钩子相比事务提交钩子更难实现，因为各种各样的情况都可能造成隐式回滚。

比如，如果数据库连接被删除，因为进程被杀而没有机会正常关闭，回滚钩子将不会运行。

解决方法是：与其在执行事务时（原子操作）进行某项操作，当事务执行失败后再取消这项操作，不如使用 on_commit() 来延迟该项操作，直到事务成功后再进行操作。毕竟事务成功后你才能确保之后的操作是有意义的。

事务

事务是指具有原子性的一系列数据库操作。即使你的程序崩溃，数据库也会确保这些操作要么全部完成要么全部都未执行。

Django doesn't provide an API to start a transaction. The expected way to start a transaction is to disable autocommit with set_autocommit().

进入事务后，你可以选择在 commit() 之前应用执行的更改，或者使用 rollback() 取消它们。这些函数在 django.db.transaction 中定义。

commit(using=None)[源代码]

rollback(using=None)[源代码]

这些函数使接受一个 using 参数表示所要操作的数据库。如果未提供，则 Django 使用 "default" 数据库。

当一个原子 atomic() 事务处于活动状态时， Django 将会拒绝进行事务提交或者事务回滚，因为这样会破坏原子性。

MySQL 中的事务

如果你正在使用 MySQL，表可能支持或不支持事务；它取决于 MySQL 版本和表的类型。（表类型是指 "InnoDB" 或 "MyISAM" 之类的东西）MySQL 事务的特性超出了本文的范围，但 MySQL 站点有 MySQL 事务的相关信息。

如果 MySQL 安装时没有支持事务，然后 Django 将始终在自动提交模式中运行：语句将在它们调用的时候被执行和提交。如果 MySQL 安装时支持了事务，Django 将像本文说的那样处理事务。

处理 PostgreSQL 事务中的异常

在一个事务里，当对 PostgreSQL 游标的调用引发了异常（通常是 IntegrityError），在同一事务中的随后的 SQL 将会出现 "当前事务中止，查询被忽略，直到事务块结束" 的错误 。虽然 save() 的基本用法不太可能在 PostgreSQL 中引发异常，但还有更高级的用法模式，比如保存具有唯一字段的对象，保存使用 force_insert/force_update 标记，或调用自定义的 SQL。

有几种方法来从这种错误中恢复。

a.save() # Succeeds, but may be undone by transaction rollback
try:
    b.save() # Could throw exception
except IntegrityError:
    transaction.rollback()
c.save() # Succeeds, but a.save() may have been undone

a.save() # Succeeds, and never undone by savepoint rollback
sid = transaction.savepoint()
try:
    b.save() # Could throw exception
    transaction.savepoint_commit(sid)
except IntegrityError:
    transaction.savepoint_rollback(sid)
c.save() # Succeeds, and a.save() is never undone