Skip to main content

信号

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

参见

有关如何注册和接收信号的信息,请参阅 信号分配器 上的文档。

认证框架 发送 当用户登录/注销时的信号

模型信号

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__() 的关键字参数字典:

例如,教程 有这一行:

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() 时要更新的字段集,如果 update_fields 未传递给 save(),则为 None

post_save

django.db.models.signals.post_save

pre_save,但是在 save() 方法结束时发送。

与此信号一起发送的参数:

sender

模型类。

instance

正在保存的实际实例。

created

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

raw

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

using

正在使用的数据库别名。

update_fields

要传送到 Model.save() 时要更新的字段集,如果 update_fields 未传递给 save(),则为 None

pre_delete

django.db.models.signals.pre_delete

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

与此信号一起发送的参数:

sender

模型类。

instance

要删除的实际实例。

using

正在使用的数据库别名。

post_delete

django.db.models.signals.post_delete

pre_delete,但发送在模型的 delete() 方法和查询集的 delete() 方法的结尾。

与此信号一起发送的参数:

sender

模型类。

instance

要删除的实际实例。

请注意,对象将不再存在于数据库中,因此请小心使用此实例执行的操作。

using

正在使用的数据库别名。

m2m_changed

django.db.models.signals.m2m_changed

在模型实例上更改 ManyToManyField 时发送。严格地说,这不是一个模型信号,因为它是由 ManyToManyField 发送的,但由于它补充了 pre_save/post_savepre_delete/post_delete,当涉及跟踪模型的更改,它包括在这里。

与此信号一起发送的参数:

sender

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

instance

其多对多关系被更新的实例。这可以是 sender 的实例,或者 ManyToManyField 所关联的类的实例。

action

指示在关系上执行的更新类型的字符串。这可以是以下之一:

"pre_add"

已发送的 before 将一个或多个对象添加到关系中。

"post_add"

已发送的 after 将一个或多个对象添加到关系中。

"pre_remove"

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

"post_remove"

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

"pre_clear"

发送 before 关系被清除。

"post_clear"

发送 after 关系被清除。

reverse

指示关系的哪一侧被更新(即,如果它是正被修改的正向或反向关系)。

model

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

pk_set

对于 pre_addpost_addpre_removepost_remove 操作,这是已添加到关系或从关系中删除的一组主键值。

对于 pre_clearpost_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

FalsePizza 包含 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

TruePizza 包含 ManyToManyField,所以这个调用修改了反向关系)

model

Pizza (从 Topping 中删除的对象的类)

pk_set

{p.id} (因为只有 Pizza 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

如果 interactiveTrue,则可以提示用户在命令行上输入内容。如果 interactiveFalse,监听这个信号的函数不应该尝试提示任何东西。

例如,当 interactiveTrue 时,django.contrib.auth 应用程序仅提示创建超级用户。

using

命令将在其上操作的数据库的别名。

plan
New in Django 1.10.

将用于迁移运行的迁移计划。虽然计划不是公共API,这允许在需要知道计划的罕见情况。计划是一个二元组列表,其中第一个项目是迁移类的实例,第二个项目显示迁移是回滚(True)还是应用(False)。

apps
New in Django 1.10.

包含迁移之前项目状态的 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

如果 interactiveTrue,则可以提示用户在命令行上输入内容。如果 interactiveFalse,监听这个信号的函数不应该尝试提示任何东西。

例如,当 interactiveTrue 时,django.contrib.auth 应用程序仅提示创建超级用户。

using

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

plan
New in Django 1.10.

用于迁移运行的迁移计划。虽然计划不是公共API,这允许在需要知道计划的罕见情况。计划是一个二元组列表,其中第一个项目是迁移类的实例,第二个项目显示迁移是回滚(True)还是应用(False)。

apps
New in 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() 中注册。重新创建 AppConfig 用于使用修改的 INSTALLED_APPS 集(例如当设置被覆盖时)运行的测试,并且这样的信号应当针对每个新的 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响应时发送。

注解

一些WSGI服务器和中间件在处理请求后不总是在响应对象上调用 close,最值得注意的是在1.2.6之前的uWSGI和到2.0.7的Sentry的错误报告中间件。在这些情况下,根本不发送该信号。这可能导致空闲连接到数据库和内存缓存服务器。

与此信号一起发送的参数:

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

更改后的设置值。对于最初不存在的设置,在“拆卸”阶段中,valueNone

enter

布尔值; True 如果应用设置,False 如果恢复。

template_rendered

django.test.signals.template_rendered

在测试系统呈现模板时发送。这个信号在Django服务器的正常操作期间不发射 - 它只在测试期间可用。

与此信号一起发送的参数:

sender

呈现的 Template 对象。

template

与发件人相同

context

渲染模板的 Context

数据库包装器

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

connection_created

django.db.backends.signals.connection_created

当数据库包装器与数据库进行初始连接时发送。如果你想发送任何post连接命令到SQL后端,这是特别有用。

与此信号一起发送的参数:

sender

数据库包装器类 - 即 django.db.backends.postgresql.DatabaseWrapperdjango.db.backends.mysql.DatabaseWrapper

connection

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