Django信号量

时间：2019-07-27 23:31:41 阅读：104 评论：0 收藏：0 [点我收藏+]

摘自官方文档

使用

技术分享图片

信号

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: 已打开的数据库连接。这可以在多数据库配置中使用，以区分来自不同数据库的连接信号。

Django信号量

原文：https://www.cnblogs.com/limengda/p/11257117.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年09月23日 (328)
2021年09月24日 (313)
2021年09月17日 (191)
2021年09月15日 (369)
2021年09月16日 (411)
2021年09月13日 (439)
2021年09月11日 (398)
2021年09月12日 (393)
2021年09月10日 (160)
2021年09月08日 (222)