Django发送的所有信号的列表。所有内置信号均使用 send() 方法。
参见
请参阅 signal dispatcher 有关如何注册和接收信号的信息。
这个 authentication framework 发送 signals when a user is logged in / out .
这个 django.db.models.signals 模块定义了模型系统发送的一组信号。
警告
信号会使代码更难维护。考虑在 custom manager ，更新模型并执行附加逻辑，否则 overriding model methods 在使用模型信号之前。
警告
其中许多信号是通过各种模型方法发送的，比如 __init__() 或 save() 您可以在自己的代码中重写。
如果在模型上重写这些方法，则必须调用父类的方法才能发送这些信号。
另外请注意，Django默认情况下将信号处理程序存储为弱引用，因此如果处理程序是本地函数，则可能会被垃圾收集。为了防止这种情况，通过 weak=False 当你调用信号的时候 connect() .
备注
模型信号 sender 通过指定接收器的完整应用程序标签，可以在连接接收器时延迟引用模型。例如，一个 Question 在中定义的模型 polls 应用程序可以引用为 'polls.Question' . 这种引用在处理循环导入依赖项和可交换模型时非常方便。
pre_init¶每当您实例化一个django模型时，此信号将在模型的开始处发送 __init__() 方法。
随此信号发送的参数：
sender刚刚创建了实例的模型类。
args传递给的位置参数列表 __init__() .
kwargs传递给的关键字参数字典 __init__() .
例如， tutorial 有这样一行：
q = Question(question_text="What's new?", pub_date=timezone.now())
将参数发送到 pre_init 处理程序为：
论证 |
价值 |
|---|---|
|
|
|
|
|
|
post_init¶就像pre-init，但这个是在 __init__() 方法完成。
随此信号发送的参数：
sender如上所述：刚刚创建实例的模型类。
instance刚刚创建的模型的实际实例。
备注
instance._state 发送前未设置 post_init 信号，所以 _state 属性总是有其默认值。例如， _state.db 是 None .
警告
出于性能原因，不应在 pre_init 或 post_init 发出信号，因为在queryset迭代期间将对返回的每个实例执行它们。
pre_save¶这是在模型的开头发送的 save() 方法。
随此信号发送的参数：
sender模型类。
instance正在保存的实际实例。
raw布尔值； True 如果模型完全按照显示的方式保存(即，在加载 fixture )。不应查询/修改数据库中的其他记录，因为数据库可能尚未处于一致状态。
using正在使用的数据库别名。
update_fields传递到的要更新的字段集 Model.save() 或 None 如果 update_fields 没有传给 save() .
post_save¶随此信号发送的参数：
sender模型类。
instance正在保存的实际实例。
created布尔； True 如果创建了新记录。
raw布尔值； True 如果模型完全按照显示的方式保存(即，在加载 fixture )。不应查询/修改数据库中的其他记录，因为数据库可能尚未处于一致状态。
using正在使用的数据库别名。
update_fields传递到的要更新的字段集 Model.save() 或 None 如果 update_fields 没有传给 save() .
pre_delete¶在模型的开头发送 delete() 方法和查询集 delete() 方法。
随此信号发送的参数：
sender模型类。
instance正在删除的实际实例。
using正在使用的数据库别名。
origin
删除的起始点是
Model或QuerySet班级。
post_delete¶喜欢 pre_delete ，但在模型的末尾发送 delete() 方法和查询集 delete() 方法。
随此信号发送的参数：
sender模型类。
instance正在删除的实际实例。
请注意，该对象将不再位于数据库中，因此请小心处理该实例。
using正在使用的数据库别名。
origin
删除的起始点是
Model或QuerySet班级。
m2m_changed¶发送时 ManyToManyField is changed on a model instance. Strictly speaking, this is not a model signal since it is sent by the ManyToManyField, but since it complements the 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 操作，这是一组将要或已经添加到关系中的主键值。这可能是提交要添加的值的一个子集，因为insert必须过滤现有值以避免数据库 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的模型系统，就发送。Django在内部使用此信号；它通常不用于第三方应用程序。
因为此信号是在应用程序注册表填充过程中发送的，并且 AppConfig.ready() 在应用程序注册表完全填充后运行，接收器无法在该方法中连接。一种可能是连接它们 AppConfig.__init__() 相反，注意不要将模型或触发器调用导入到应用程序注册表。
随此信号发送的参数：
sender刚刚准备的模型类。
信号发送 django-admin .
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，但这允许在极少数情况下有必要了解该计划。计划是一个两元组的列表，第一项是迁移类的实例，第二项显示迁移是否回滚 (True )或已应用 (False )。
appspost_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，但这允许在极少数情况下有必要了解该计划。计划是一个两元组的列表，第一项是迁移类的实例，第二项显示迁移是否回滚 (True )或已应用 (False )。
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 实例作为sender参数，请确保在 ready() . AppConfig 对于使用修改后的 INSTALLED_APPS （例如当设置被覆盖时），并且应为每个新的 AppConfig 实例。
核心框架在处理请求时发送的信号。
警告
信号会使代码更难维护。考虑 using a middleware 在使用请求/响应信号之前。
request_started¶当Django开始处理HTTP请求时发送。
随此信号发送的参数：
sender处理程序类——例如 django.core.handlers.wsgi.WsgiHandler --处理了请求。
environ这个 environ 提供给请求的词典。
request_finished¶当Django完成向客户端传递HTTP响应时发送。
随此信号发送的参数：
sender处理程序类，如上所述。
got_request_exception¶每当Django在处理传入的HTTP请求时遇到异常时，就会发送此信号。
随此信号发送的参数：
sender未使用的（总是） None ）
request这个 HttpRequest 对象。
仅在以下情况下发送信号 running tests .
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服务器的正常运行期间发出——它仅在测试期间可用。
随此信号发送的参数：
启动数据库连接时由数据库包装器发送的信号。
connection_created¶当数据库包装器与数据库建立初始连接时发送。如果您想将任何后连接命令发送到SQL后端，这尤其有用。
随此信号发送的参数：
sender数据库包装类——即 django.db.backends.postgresql.DatabaseWrapper 或 django.db.backends.mysql.DatabaseWrapper 等。
connection已打开的数据库连接。这可以在多数据库配置中使用，以区分不同数据库的连接信号。
12月 18, 2023