Django信号量

摘自官方文档

使用

信号

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

 参见

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

用户登录/注销时， 身份验证框架会 发送 信号 。

模型信号

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

 警告

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

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

另请注意，Django默认将信号处理程序存储为弱引用，因此如果您的处理程序是本地函数，则可能是垃圾回收。为了防止这种情况，请 weak=False 在调用信号时通过 connect() 。

 注解

sender 通过指定其完整的应用标签来连接接收器时，可以懒惰地引用模型信号模型。例如，应用程序中 Answer 定义的 模型 polls 可以引用为 '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() ，或者 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

正在使用的数据库别名。

pre_delete

django.db.models.signals.post_delete

喜欢 pre_delete ，但是在模型的 delete() 方法和查询集的方法 结束时发送 delete() 。

使用此信号发送的参数：

sender

模型类。

instance

要删除的实际实例。

请注意，该对象将不再存在于数据库中，因此请谨慎对待此实例。

using

正在使用的数据库别名。

 

m2m_changed

django.db.models.signals.m2m_changed

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

正在使用的数据库别名。

例如，如果a 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)

View Code

然后做了这样的事情：

>>> 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}（因为只从关系中删除）Pizza p
using	"default" （因为默认路由器在这里发送写入）

 

 

class_prepared

django.db.models.signals.class_prepared

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

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

使用此信号发送的参数：

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

例如， django.contrib.auth 应用程序只提示，当创建一个超级用户 interactive 是 True 。

using

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

plan

将用于迁移运行的迁移计划。虽然该计划不是公共API，但这允许在必要时知道该计划的极少数情况。计划是两元组的列表，第一项是迁移类的实例，第二项显示迁移是否已回滚（ 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 。

using

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

plan

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

apps

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

例如，您可以 AppConfig 像这样注册一个回调 ：

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)

View Code

 

 注解

如果您提供 AppConfig 实例作为sender参数，请确保已注册信号 ready() 。 AppConfig 对于使用修改集 INSTALLED_APPS （例如，当覆盖设置时）运行的测试，将重新创建s，并且应为每个新 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响应时发送。

使用此信号发送的参数：

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

更改后的设置值。对于最初不存在的设置，在“拆卸”阶段， 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

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

转载于:https://www.cnblogs.com/limengda/p/11257117.html