Django信号量

摘自官方文档

使用

信号

Django发送的所有信号的列表。使用该send()方法发送所有内置信号。

参见

有关如何注册和接收信号的信息，请参阅信号调度器上的文档。

用户登录/注销时，身份验证框架会发送信号。

模型信号

该django.db.models.signals模块定义了模型系统发送的一组信号。

警告

其中许多信号是通过各种模型方法发送的， __init__()或者save()您可以在自己的代码中覆盖。

如果在模型上覆盖这些方法，则必须调用父类的方法来发送此信号。

另请注意，Django默认将信号处理程序存储为弱引用，因此如果您的处理程序是本地函数，则可能是垃圾回收。为了防止这种情况，请weak=False在调用信号时通过connect()。

注解

sender通过指定其完整的应用标签来连接接收器时，可以懒惰地引用模型信号模型。例如，应用程序中Answer定义的 模型polls可以引用为'polls.Answer'。在处理循环导入依赖项和可交换模型时，这种引用非常方便。

pre_init

django.db.models.signals.pre_init

每当您实例化Django模型时，此信号都会在模型__init__()方法的开头发送。

使用此信号发送的参数：

sender

刚创建实例的模型类。

args

传递给的位置参数列表__init__()：

kwargs

传递给关键字参数的字典__init__()：

例如，教程有这一行：

p = Poll(question="What's up?", pub_date=datetime.now())

发送给pre_init处理程序的参数是：

争论	值
sender	Poll （班级本身）
args	[]（一个空列表，因为没有传递给位置参数__init__()。）
kwargs	{'question': "What's up?", 'pub_date': datetime.now()}

 

post_init

django.db.models.signals.post_init

和pre_init一样，但是这个__init__()方法在方法完成时发送。

使用此信号发送的参数：

sender

如上所述：刚创建实例的模型类。

instance

刚刚创建的模型的实际实例。

pre_save

django.db.models.signals.pre_save

这是在模型save()方法的开头发送的。

使用此信号发送的参数：

sender

模型类。

instance

保存的实际实例。

raw

布尔值; True如果模型完全按照提供的方式保存（即加载夹具时）。不应该查询/修改数据库中的其他记录，因为数据库可能尚未处于一致状态。

using

正在使用的数据库别名。

update_fields

要传递给更新的字段集Model.save()，或者None如果update_fields未传递给它save()。

post_save

django.db.models.signals.post_save¶

喜欢pre_save，但在save()方法结束时发送 。

使用此信号发送的参数：

sender

模型类。

instance

保存的实际实例。

created

布尔值; True如果创建了新记录。

raw

布尔值; True如果模型完全按照提供的方式保存（即加载夹具时）。不应该查询/修改数据库中的其他记录，因为数据库可能尚未处于一致状态。

using

正在使用的数据库别名。

update_fields

要传递给更新的字段集Model.save()，或者None如果update_fields未传递给它save()。

pre_delete

django.db.models.signals.pre_delete

在模型的delete()方法和查询集的方法的开头发送delete()。

使用此信号发送的参数：

sender

模型类。

instance

要删除的实际实例。

using

正在使用的数据库别名。

pre_delete

django.db.models.signals.post_delete

喜欢pre_delete，但是在模型的delete()方法和查询集的方法 结束时发送 delete()。

使用此信号发送的参数：

sender

模型类。

instance

要删除的实际实例。

请注意，该对象将不再存在于数据库中，因此请谨慎对待此实例。

using

正在使用的数据库别名。

m2m_changed

django.db.models.signals.m2m_changed

ManyToManyField在模型实例上更改a 时发送。严格来说，这不是一个模型信号，因为它是由它发送的 ManyToManyField，但由于它补充了 pre_save/ post_save和pre_delete/ post_delete当跟踪模型的变化时，它包含在这里。

使用此信号发送的参数：

sender

中间模型类描述 ManyToManyField。定义多对多字段时，将自动创建此类; 您可以使用through多对多字段中的属性访问它 。

instance

更新多对多关系的实例。这可以是与之相关sender的类的实例，也可以ManyToManyField是与之相关的类的 实例。

action

一个字符串，指示对关系执行的更新类型。这可以是以下之一：

"pre_add"

在将一个或多个对象添加到关系之前发送。

"post_add"

将一个或多个对象添加到关系后发送。

"pre_remove"

在从关系中删除一个或多个对象之前发送。

"post_remove"

从关系中删除一个或多个对象后发送。

"pre_clear"

在关系被清除之前发送。

"post_clear"

关系清除后发送。

reverse

指示关系的哪一侧更新（即，是否正在修改正向或反向关系）。

model

从关系中添加，删除或清除的对象的类。

pk_set

对于pre_add，post_add，pre_remove和post_remove的动作，这是一组已被添加到或从关系移除主键值。

对于pre_clear和post_clear行动，这是None。

using

正在使用的数据库别名。

例如，如果a Pizza可以有多个Topping对象，则建模如下：

class Topping(models.Model):
# ...
pass

class Pizza(models.Model):
# ...
toppings = models.ManyToManyField(Topping)
如果我们连接这样的处理程序：
from django.db.models.signals import m2m_changed

def toppings_changed(sender, **kwargs):
# Do something
pass

m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)

然后做了这样的事情：

>>> p = Pizza.objects.create(...)

>>> t = Topping.objects.create(...)

>>> p.toppings.add(t)

发送给m2m_changed处理程序的参数（toppings_changed在上面的例子中）将是：

争论	值
sender	Pizza.toppings.through （中级m2m级）
instance	p（Pizza正在修改的实例）
action	"pre_add"（后跟一个单独的信号"post_add"）
reverse	False（Pizza包含 ManyToManyField，所以这个调用修改了前向关系）
model	Topping（添加到的对象的类 Pizza）
pk_set	{t.id}（因为只添加到关系中）Topping t
using	"default" （因为默认路由器在这里发送写入）

如果我们这样做的话：

>>> t.pizza_set.remove(p)

发送给m2m_changed处理程序的参数是：

争论	值
sender	Pizza.toppings.through （中级m2m级）
instance	t（Topping正在修改的实例）
action	"pre_remove"（后跟一个单独的信号"post_remove"）
reverse	True（Pizza包含 ManyToManyField，所以这个调用修改了反向关系）
model	Pizza（从中删除的对象的类 Topping）
pk_set	{p.id}（因为只从关系中删除）Pizza p
using	"default" （因为默认路由器在这里发送写入）

 

class_prepared

django.db.models.signals.class_prepared

每当模型类被“准备好”时发送 - 也就是说，一旦定义了模型并在Django的模型系统中注册。Django在内部使用这个信号; 它通常不用于第三方应用程序。

由于此信号是在app注册表填充过程中发送的，并且 AppConfig.ready()在app注册表完全填充后运行，因此无法在该方法中连接接收器。一种可能性是连接它们AppConfig.__init__()，注意不要导入模型或触发对app注册表的调用。

使用此信号发送的参数：

sender

刚准备的模型类。

管理信号

django-admin发送的信号。

pre_migrate

django.db.models.signals.pre_migrate

migrate在开始安装应用程序之前由命令发送。对于缺少models模块的应用程序，它不会发出。

使用此信号发送的参数：

sender

AppConfig要迁移/同步的应用程序的实例。

app_config

与...相同sender。

verbosity

表示manage.py在屏幕上打印的信息量。请参阅--verbosity旗帜了解详情。

侦听的函数pre_migrate应根据此参数的值调整它们输出到屏幕的内容。

interactive

如果interactive是True，则提示用户在命令行上输入内容是安全的。如果interactive是False，侦听此信号的功能不应尝试提示任何内容。

例如，django.contrib.auth应用程序只提示，当创建一个超级用户interactive是True。

using

命令将在其上运行的数据库的别名。

plan

将用于迁移运行的迁移计划。虽然该计划不是公共API，但这允许在必要时知道该计划的极少数情况。计划是两元组的列表，第一项是迁移类的实例，第二项显示迁移是否已回滚（True）或已应用（False）。

apps

Apps在迁移运行之前包含项目状态的实例。应该使用它来代替全局 apps注册表来检索要对其执行操作的模型。

post_migrate

django.db.models.signals.post_migrate

在结束时发送migrate（即使没有运行迁移）和 flush命令。对于缺少models模块的应用程序，它不会发出 。

此信号的处理程序不得执行数据库模式更改，因为这样做可能会导致flush命令在migrate命令期间运行时失败 。

使用此信号发送的参数：

sender

AppConfig刚刚安装的应用程序的实例。

app_config

与...相同sender。

verbosity

表示manage.py在屏幕上打印的信息量。请参阅--verbosity旗帜了解详情。

侦听的函数post_migrate应根据此参数的值调整它们输出到屏幕的内容。

interactive

如果interactive是True，则提示用户在命令行上输入内容是安全的。如果interactive是False，侦听此信号的功能不应尝试提示任何内容。

例如，django.contrib.auth应用程序只提示，当创建一个超级用户interactive是True。

using

用于同步的数据库别名。默认为default数据库。

plan

用于迁移运行的迁移计划。虽然该计划不是公共API，但这允许在必要时知道该计划的极少数情况。计划是两元组的列表，第一项是迁移类的实例，第二项显示迁移是否已回滚（True）或已应用（False）。

apps

Apps迁移运行后包含项目状态的实例。应该使用它来代替全局 apps注册表来检索要对其执行操作的模型。

例如，您可以AppConfig像这样注册一个回调 ：

class Topping(models.Model):
# ...
pass

class Pizza(models.Model):
# ...
toppings = models.ManyToManyField(Topping)
如果我们连接这样的处理程序：
from django.db.models.signals import m2m_changed

def toppings_changed(sender, **kwargs):
# Do something
pass

m2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)

注解

如果您提供AppConfig实例作为sender参数，请确保已注册信号 ready()。AppConfig对于使用修改集INSTALLED_APPS（例如，当覆盖设置时）运行的测试，将重新创建s，并且应为每个新AppConfig实例连接此类信号。

请求/响应信号

处理请求时核心框架发送的信号。

request_started

django.core.signals.request_started

Django开始处理HTTP请求时发送。

使用此信号发送的参数：

sender

处理程序类 - 例如django.core.handlers.wsgi.WsgiHandler- 处理请求。

environ

environ提供给请求的字典。

request_finished

django.core.signals.request_finished

当Django完成向客户端发送HTTP响应时发送。

使用此信号发送的参数：

sender

处理程序类，如上所述。

got_request_exception

django.core.signals.got_request_exception

只要Django在处理传入的HTTP请求时遇到异常，就会发送此信号。

使用此信号发送的参数：

sender

处理程序类，如上所述。

request

的HttpRequest对象。

测试信号

仅在运行测试时发送的信号。

setting_changed

django.test.signals.setting_changed

当通过django.test.TestCase.settings()上下文管理器或 django.test.override_settings()装饰器/上下文管理器更改设置的值时，将发送此信号 。

它实际上发送了两次：当应用新值（“设置”）和恢复原始值时（“拆除”）。使用enter参数来区分这两者。

您也可以导入此信号，django.core.signals以避免django.test在非测试情况下导入。

使用此信号发送的参数：

sender

设置处理程序。

setting

设置的名称。

value

更改后的设置值。对于最初不存在的设置，在“拆卸”阶段，value是None。

enter

布尔值; True如果应用该设置，False则恢复。

template_rendered

django.test.signals.template_rendered

在测试系统呈现模板时发送。在Django服务器的正常操作期间不会发出此信号 - 它仅在测试期间可用。

使用此信号发送的参数：

sender

Template呈现的对象。

template

与发件人相同

context

在Context与该模板被渲染。

数据库包装器

启动数据库连接时由数据库包装程序发送的信号。

connection_created

django.db.backends.signals.connection_created

数据库包装器与数据库建立初始连接时发送。如果您要将任何后连接命令发送到SQL后端，这将特别有用。

使用此信号发送的参数：

sender

数据库包装类 - 即 django.db.backends.postgresql.DatabaseWrapper或 django.db.backends.mysql.DatabaseWrapper等

connection

已打开的数据库连接。这可以在多数据库配置中使用，以区分来自不同数据库的连接信号。