信号¶

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

请参见

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

当用户登录/退出时，authentication framework发送signals when a user is logged in / out

模型信号¶

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

警告

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

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

还要注意，Django默认将信号处理程序存储为弱引用，所以如果你的处理程序是本地函数，那么可能是垃圾回收。为了防止这种情况，请在调用信号的connect()时传递weak=False。

注

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

`pre_init`¶

django.db.models.signals.pre_init¶

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

带有此信号的参数：

sender: 刚创建了一个实例的模型类。
args: 传递给__init__()的位置参数列表：
kwargs: 传递给__init__()的关键字参数的字典：

例如，tutorial具有以下一行：

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: The set of fields to update as passed to Model.save(), or None if update_fields wasn’t passed to save().

`post_save`¶

django.db.models.signals.post_save¶

像pre_save一样，但是在save()方法的末尾发送。

带有此信号的参数：

sender: 模型类。
instance: 正在保存的实际实例。
created: 一个布尔值True如果创建了新记录。
raw: 一个布尔值True如果模型按照显示的方式保存（即当加载固定装置时）。不应该查询/修改数据库中的其他记录，因为数据库可能尚未处于一致状态。
using: 正在使用的数据库别名。
update_fields: The set of fields to update as passed to Model.save(), or None if update_fields wasn’t passed to save().

`pre_delete`¶

django.db.models.signals.pre_delete¶

在模型的delete()方法和queryset的delete()方法的开头发送。

带有此信号的参数：

sender: 模型类。
instance: 正在删除的实际实例。
using: 正在使用的数据库别名。

`post_delete`¶

django.db.models.signals.post_delete¶

像pre_delete一样，但是在模型的delete()方法和queryset的delete()方法的末尾发送。

带有此信号的参数：

sender

模型类。

instance

正在删除的实际实例。

请注意，该对象将不再位于数据库中，所以要非常小心使用此实例。

using

正在使用的数据库别名。

`m2m_changed`¶

django.db.models.signals.m2m_changed¶

在模型实例上更改了ManyToManyField时发送。严格来说，这不是一个模型信号，因为它是由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

正在使用的数据库别名。

例如，如果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}`（因为只有`比萨 p`从关系中删除）
`using`	`"default"`（由于默认路由器在此发送写入）

`class_prepared`¶

django.db.models.signals.class_prepared¶

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

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

使用此信号发送的参数：

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，则侦听此信号的功能不应尝试提示任何内容。

例如，当interactive为True时，django.contrib.auth应用程序仅提示创建超级用户。

using

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

plan

Django中的新功能1.10。

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

apps

Django中的新功能1.10。

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

`post_migrate`¶

django.db.models.signals.post_migrate¶

在migrate（即使不进行迁移）和flush命令的末尾发送。对于缺少models模块的应用，不会发送。

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

带有此信号的参数：

sender

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

APP_CONFIG

与sender相同。

verbosity

指示manage.py在屏幕上打印多少信息。有关详细信息，请参阅--verbosity标志。

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

interactive

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

例如，当interactive为True时，django.contrib.auth应用程序仅提示创建超级用户。

using

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

plan

Django中的新功能1.10。

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

apps

Django中的新功能1.10。

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

例如，您可以在AppConfig中注册回调，如下所示：

from django.apps import AppConfig
from django.db.models.signals import post_migrate

def my_callback(sender, **kwargs):
    # Your specific logic here
    pass

class MyAppConfig(AppConfig):
    ...

    def ready(self):
        post_migrate.connect(my_callback, sender=self)

注

如果您提供AppConfig实例作为发件人参数，请确保信号已在ready()中注册。 AppConfigs are recreated for tests that run with a modified set of INSTALLED_APPS (such as when settings are overridden) and such signals should be connected for each new AppConfig instance.

请求/响应信号¶

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

`request_started`¶

django.core.signals。 request_started T0> ¶ T1>

当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 T0> ¶ T1>

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

带有此信号的参数：

sender: 处理程序类，如上。
request: HttpRequest对象。

测试信号¶

信号只在running tests时发送。

`setting_changed`¶

django.test.signals.setting_changed¶

当通过django.test.TestCase.settings()上下文管理器或django.test.override_settings()装饰器/上下文管理器

实际发送两次：应用新值（“setup”）和恢复原始值（“拆除”）时。使用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: 打开的数据库连接。这可以在多数据库配置中使用，以区分来自不同数据库的连接信号。

Django 1.11.6 文档

信号¶

模型信号¶

`pre_init`¶

`post_init`¶

`pre_save`¶

`post_save`¶

`pre_delete`¶

`post_delete`¶

`m2m_changed`¶

`class_prepared`¶

管理信号¶

`pre_migrate`¶

`post_migrate`¶

请求/响应信号¶

`request_started`¶

`request_finished`¶

`got_request_exception`¶

测试信号¶

`setting_changed`¶

`template_rendered`¶

数据库包装器¶

`connection_created`¶

目录

浏览

你在这里：

这一页

最后更新：

Django 1.11.6 文档

信号¶

模型信号¶

pre_init¶

post_init¶

pre_save¶

post_save¶

pre_delete¶

post_delete¶

m2m_changed¶

class_prepared¶

管理信号¶

pre_migrate¶

post_migrate¶

请求/响应信号¶

request_started¶

request_finished¶

got_request_exception¶

测试信号¶

setting_changed¶

template_rendered¶

数据库包装器¶

connection_created¶

最后更新：

`pre_init`¶

`post_init`¶

`pre_save`¶

`post_save`¶

`pre_delete`¶

`post_delete`¶

`m2m_changed`¶

`class_prepared`¶

`pre_migrate`¶

`post_migrate`¶

`request_started`¶

`request_finished`¶

`got_request_exception`¶

`setting_changed`¶

`template_rendered`¶

`connection_created`¶