pre_init¶

django.db.models.signals.pre_init¶

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

随此信号发送的参数

sender

刚刚创建实例的模型类。

args

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

kwargs

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

例如，教程有以下行

q = Question(question_text="What's new?", pub_date=timezone.now())

发送到 pre_init 处理程序的参数将是

post_init¶

django.db.models.signals.post_init¶

与 pre_init 类似，但此信号在 __init__() 方法完成时发送。

随此信号发送的参数

sender

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

instance

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

注意

instance._state 在发送 post_init 信号之前未设置，因此 _state 属性始终具有其默认值。例如，_state.db 为 None。

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

正在使用的数据库别名。

origin

删除的来源是 Model 或 QuerySet 类的实例。

post_delete¶

django.db.models.signals.post_delete¶

类似于 pre_delete，但发送到模型的 delete() 方法和查询集的 delete() 方法的末尾。

随此信号发送的参数

sender

模型类。

instance

正在删除的实际实例。

请注意，对象将不再位于数据库中，因此请非常小心地处理此实例。

using

正在使用的数据库别名。

origin

删除的来源是 Model 或 QuerySet 类的实例。

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 操作，这是一组将被或已添加到关系中的主键值。这可能是提交要添加的值的子集，因为插入必须过滤现有值以避免数据库 IntegrityError。

对于 pre_remove 和 post_remove 操作，这是一组提交要从关系中删除的主键值。这并不取决于值是否实际上将被或已删除。特别是，可以提交不存在的值，它们将出现在 pk_set 中，即使它们对数据库没有影响。

对于 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）的参数将是

如果我们执行类似以下操作

>>> t.pizza_set.remove(p)

发送到 m2m_changed 处理程序的参数将为

class_prepared¶

django.db.models.signals.class_prepared¶

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

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

与此信号一起发送的参数

sender

刚刚准备好的模型类。

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 时才提示创建超级用户。

stdout

一个类流对象，详细输出应重定向到该对象。

using

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

plan

用于迁移运行的迁移计划。虽然计划不是公共 API，但这允许在需要了解计划的罕见情况下使用。计划是 2 元组的列表，第一个项目是迁移类的实例，第二个项目显示迁移是回滚（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 时才提示创建超级用户。

stdout

一个类流对象，详细输出应重定向到该对象。

using

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

plan

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

apps

包含迁移运行后项目状态的 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)

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

未使用（始终为 None）。

请求

HttpRequest 对象。

setting_changed¶

django.test.signals.setting_changed¶

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

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

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

随此信号发送的参数

sender

设置处理程序。

设置

设置的名称。

值

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

输入

布尔值；如果应用设置，则为 True，如果还原，则为 False。

template_rendered¶

django.test.signals.template_rendered¶

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

随此信号发送的参数

sender

Template 对象已呈现。

模板

与发送方相同

上下文

渲染模板的 Context。

connection_created¶

django.db.backends.signals.connection_created¶

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

随此信号发送的参数

sender

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

connection

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