django-transaction-signals-do-not-use 1.0

tl;dr

对于在当前事务成功提交后运行代码的常用用例，请使用 django-transaction-hooks。它有一些粗糙的边缘，但它是合理的。

为什么？

Django不提供事务信号，因为这是一个糟糕的想法。以下“局限性”段落中的一些原因将很明显。其他原因可以在ticket 14051 和 django-developers 邮件列表中找到。然而，我已经厌倦了这个争论。人们无论如何都会自己伤害自己。

此包将帮助您亲身体验事务信号的问题。

自行承担风险使用。我不会。

如何？

将'transaction_signals'添加到您的INSTALLED_APPS设置中。

这将修补Django的事务管理功能。

然后您可以注册事务信号接收器

from django.dispatch import receiver
from transaction_signals import post_commit

@receiver(post_commit)
def print_commits(sender, **kwargs):
    print("COMMIT on %s" % sender)

信号

信号在transaction_signals包中可用。它们的语义很明显，除非它们不明显。

连接信号

• pre_open

• post_open

• pre_close

• post_close

自动提交信号

• pre_set_autocommit

• post_set_autocommit

事务信号

• pre_commit

• post_commit

• pre_rollback

• post_rollback

保存点信号

• pre_savepoint

• post_savepoint

• pre_savepoint_commit

• post_savepoint_commit

• pre_savepoint_rollback

• post_savepoint_rollback

sender 是数据库连接的别名，例如 'default'。所有信号都将数据库连接通过 'connection' 参数传递。此外，pre/post_open 提供一个 conn_params 参数，pre/post_set_autocommit 提供 autocommit，而 pre/post_savepoint/_commit/_rollback 提供 savepoint_id。

限制

您不能假设每次提交更改时都会发送 pre/post_commit。在自动提交模式下，即默认模式，连接时不发送信号。

您不能假设每次取消更改时都会发送 pre/post_rollback。关闭到数据库的连接将触发隐式回滚。

您不能假设每次发生隐式回滚时都会发送 pre/post_close。丢失数据库连接也会触发隐式回滚。

在发送 pre/post_savepoint 之后，您不能假设会以相同的 savepoint_id 发送 pre/post_savepoint_commit 或 pre/post_savepoint_rollback。保存点可能与更早的保存点或整个事务一起释放或回滚。

您不能在 SQLite 上使用 pre/post_set_autocommit。sqlite3 模块在非自动提交模式下不工作。

您不能在 Oracle、MSSQL 或不支持释放保存点的任何其他数据库上使用 pre/post_savepoint_commit。

这只是冰山一角。如果您在本节中学到了任何东西，我无法推荐您使用此包。实际上，我根本不推荐使用它。

替代方案

幸运的是，如果您想向 Django 的事务处理添加自定义逻辑，您有几个替代方案。它们不太可能导致愤怒、脸红、疯狂、自尊心丧失和其他不可取的副作用。

您可以在以下位置放置您的自定义逻辑

• 在中间件中，如果您只关心在 ATOMIC_REQUESTS 启用时与请求关联的事务。

• 在包装 atomic 的装饰器中，如果您有更高级的需求，特别是如果您想跟踪部分提交和回滚。

• 在数据库后端中，如果您想对数据库操作有紧密控制。由于没有公开的 API，您需要阅读源代码并了解 Django 的工作原理，而不是盲目地挂钩可能发送或可能不发送的信号。django-transaction-hooks 使用这种技术。

许可证

此包以双许可证发布：WTFPLv2 和 GPLv2。

仅包含 WTFPLv2，因为 GPLv2 太长了。