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
信号,因为它们将为查询集迭代期间返回的每个实例执行。
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
动作,这是一组将被或已经被添加到关系中的主要关键字值。这可能是提交要添加的值的子集,因为插入必须过滤现有值以避免数据库 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
)。
apps
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,但这允许在极少数情况下有必要了解该计划。计划是一个两元组的列表,第一项是迁移类的实例,第二项显示迁移是否回滚 (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
已打开的数据库连接。这可以在多数据库配置中使用,以区分不同数据库的连接信号。
7月 22, 2024