Django 发送的所有信号的列表。所有内置的信号都是使用 send() 方法发送的。
django.db.models.signals 模块定义了一组由模型系统发送的信号。
pre_initLink to this heading#每当你实例化一个 Django 模型时，这个信号都会在模型的 __init__() 方法的开头发出。
用此信号发送的参数：
\nsender刚刚创建了一个实例的模型类。
\nargs传递给 __init__() 的位置参数列表。
kwargs传递给 __init__() 的关键字参数字典。
例如，教程 有这样一行：
\nq = Question(question_text="What's new?", pub_date=timezone.now())\n发送给 pre_init 处理程序的参数是：
参数 | \n值 | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
post_initLink to this heading#和 pre_init 一样，但这个是在 __init__() 方法完成后发送的。
用此信号发送的参数：
\nsender如上：刚刚创建了一个实例的模型类。
\ninstance刚刚创建的模型的实际实例。
\n\npre_saveLink to this heading#这是在模型的 save() 方法开始时发送的。
用此信号发送的参数：
\nsender模型类
\ninstance实际被保存的实例。
\nraw一个布尔值；如果模型被保存的方式与原始数据一致（即在加载 fixture 时），则为 True。在这种情况下，不应查询/修改数据库中的其他记录，因为数据库可能尚未处于一致状态。
using正在使用的数据库别名。
\nupdate_fields传递给 Model.save() 的要更新的字段集，如果 update_fields 没有传递给 save()，则为 None。
post_saveLink to this heading#就像 pre_save 一样，但在 save() 方法的最后发送。
用此信号发送的参数：
\nsender模型类
\ninstance实际被保存的实例。
\ncreated一个布尔值；True 如果创建了一个新记录。
raw一个布尔值；如果模型被保存的方式与原始数据一致（即在加载 fixture 时），则为 True。在这种情况下，不应查询/修改数据库中的其他记录，因为数据库可能尚未处于一致状态。
using正在使用的数据库别名。
\nupdate_fields传递给 Model.save() 的要更新的字段集，如果 update_fields 没有传递给 save()，则为 None。
pre_deleteLink to this heading#在模型的 delete() 方法和查询集的 delete() 方法开始时发送。
用此信号发送的参数：
\nsender模型类
\ninstance实际被删除的实例。
\nusing正在使用的数据库别名。
\noriginThe Model or QuerySet instance from which the deletion originated,\nthat is, the instance whose delete() method was invoked.
post_deleteLink to this heading#就像 pre_delete 一样，但在模型的 delete() 方法和查询集的 delete() 方法结束时发送。
用此信号发送的参数：
\nsender模型类
\ninstance实际被删除的实例。
\n请注意，该对象将不再在数据库中，所以要非常小心地处理这个实例。
\nusing正在使用的数据库别名。
\noriginThe Model or QuerySet instance from which the deletion originated,\nthat is, the instance whose delete() method was invoked.
m2m_changedLink to this heading#当一个模型实例上的 ManyToManyField 被改变时发出。严格来说，这不是一个模型信号，因为它是由 ManyToManyField 发送的，但由于它是对 pre_save/post_save 和 pre_delete/post_delete 的补充，当涉及到跟踪模型的变化时，它被包含在这里。
用此信号发送的参数：
\nsender中间模型类描述 ManyToManyField。当定义了多对多字段时，这个类会自动创建；你可以使用多对多字段上的 through 属性来访问它。
instance多对多关系被更新的实例。这可以是 sender 的实例，或者是 ManyToManyField 所关联的类的实例。
action表示对关系进行更新的类型的字符串。可以是以下类型之一：
\n"pre_add"在一个或多个对象被添加到关系 之前 发送。
\n"post_add"在一个或多个对象被添加到关系 之后 发送。
\n"pre_remove"在一个或多个对象从关系中删除 之前 发送。
\n"post_remove"在一个或多个对象从关系中删除 之后 发送。
\n"pre_clear"在关系被清除 之前 发送。
\n"post_clear"在关系被清除 之后 发送。
\nreverse表示关系的哪一面被更新（即被修改的是正向关系还是反向关系）。
\nmodel从关系中添加、删除或清除的对象的类别。
\npk_set对于 pre_add 和 post_add 动作，这是一组将被或已经被添加到关系中的主键值。这可能是提交添加的值的一个子集，因为插入必须过滤现有的值，以避免数据库 IntegrityError。
对于 pre_remove 和 post_remove 动作来说，这是一组被提交从关系中删除的主键值。这并不取决于这些值是否会被实际删除或已经被删除。特别是，不存在的值可能会被提交，并且会出现在 pk_set 中，即使它们对数据库没有影响。
对于 pre_clear 和 post_clear 动作，是 None。
using正在使用的数据库别名。
\n例如，如果一个 Pizza 可以有多个 Topping 对象，模型如下：
class Topping(models.Model):\n # ...\n pass\n\n\nclass Pizza(models.Model):\n # ...\n toppings = models.ManyToManyField(Topping)\n如果我们连接一个这样的处理程序：
\nfrom django.db.models.signals import m2m_changed\n\n\ndef toppings_changed(sender, **kwargs):\n # Do something\n pass\n\n\nm2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)\n然后执行了类似以下操作：
\n>>> p = Pizza.objects.create(...)\n>>> t = Topping.objects.create(...)\n>>> p.toppings.add(t)\n发送给 m2m_changed 处理程序的参数（在上面的例子中，toppings_changed）将是：
参数 | \n值 | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
如果我们接下来做了类似以下的操作：
\n>>> t.pizza_set.remove(p)\n发送给 m2m_changed 处理程序的参数将是：
参数 | \n值 | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
class_preparedLink to this heading#每当模型类被 "准备" 时发送，也就是说，一旦模型已经被定义并在 Django 的模型系统中注册。Django 在内部使用这个信号；它通常不在第三方应用程序中使用。
\n由于这个信号是在应用注册表填充过程中发出的，而 AppConfig.ready() 是在应用注册表完全填充后运行的，所以不能在该方法中连接接收器。一种可能是用 AppConfig.__init__() 来代替连接它们，注意不要导入模型或触发对应用注册表的调用。
用此信号发送的参数：
\nsender刚刚准备好的模型类。
\ndjango-admin 发出的信号。
\npre_migrateLink to this heading#由 migrate 命令在开始安装应用程序之前发出。对于缺乏 models 模块的应用程序，它不会发出。
用此信号发送的参数：
\nsender一个 AppConfig 实例，用于即将迁移／同步的应用程序。
app_config同 sender。
verbosity指示 manage.py 在屏幕上打印多少信息。有关详细信息，请参阅 --verbosity 标志。
监听 pre_migrate 的函数应该根据这个参数的值来调整它们向屏幕输出的内容。
interactive如果 interactive 为 True，则可以安全地提示用户在命令行上输入东西。如果 interactive 为 False，则监听该信号的函数不应试图提示任何东西。
例如 django.contrib.auth 应用只有在 interactive 为 True 时才会提示创建超级用户。
stdout一个类似于流的对象，用于重定向详细的输出。
\nusing命令将运行的数据库的别名。
\nplan将用于迁移运行的迁移计划。虽然计划不是公共 API，但这允许在必要时了解计划的情况。计划是一个包含 2 元组的列表，第一个项目是迁移类的实例，第二个项目显示迁移是回滚（True）还是应用（False）。
appsApps 的实例，包含迁移运行前的项目状态。它应该代替全局 apps 注册表来检索你要执行操作的模型。
post_migrateLink to this heading#在 migrate （即使没有运行迁移）和 flush 命令结束时发出。对于缺乏 models 模块的应用程序，它不会被发出。
该信号的处理者不能进行数据库模式的改变，因为如果在 migrate 命令期间运行 flush 命令，可能会导致后者失败。
用此信号发送的参数：
\nsender一个 AppConfig 实例，用于刚刚安装的应用程序。
app_config同 sender。
verbosity指示 manage.py 在屏幕上打印多少信息。有关详细信息，请参阅 --verbosity 标志。
监听 post_migrate 的函数应该根据这个参数的值来调整它们向屏幕输出的内容。
interactive如果 interactive 为 True，则可以安全地提示用户在命令行上输入东西。如果 interactive 为 False，则监听该信号的函数不应试图提示任何东西。
例如 django.contrib.auth 应用只有在 interactive 为 True 时才会提示创建超级用户。
stdout一个类似于流的对象，用于重定向详细的输出。
\nusing用于同步的数据库别名。默认为 default 数据库。
plan用于迁移运行的迁移计划。尽管计划不是公共 API，但这允许在必要时了解计划的情况。计划是一个包含 2 元组的列表，第一个项目是迁移类的实例，第二个项目显示迁移是回滚（True）还是应用（False）。
appsApps 的一个实例，包含迁移运行后项目的状态。它应该代替全局的 apps 注册表来检索你要执行操作的模型。
例如，你可以在一个 AppConfig 中注册一个回调，像这样：
from django.apps import AppConfig\nfrom django.db.models.signals import post_migrate\n\n\ndef my_callback(sender, **kwargs):\n # Your specific logic here\n pass\n\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n post_migrate.connect(my_callback, sender=self)\n核心框架处理请求时发出的信号。
\n\nrequest_startedLink to this heading#当 Django 开始处理一个 HTTP 请求时发送。
\n用此信号发送的参数：
\nsender处理程序类 —— 例如 django.core.handlers.wsgi.wsgiHandler —— 处理该请求。
environ向请求提供的 environ 字典。
request_finishedLink to this heading#当 Django 完成向客户端发送 HTTP 响应时发送。
\n用此信号发送的参数：
\nsender处理程序类，同上。
\ngot_request_exceptionLink to this heading#当 Django 在处理一个传入的 HTTP 请求时遇到异常时，就会发出这个信号。
\n用此信号发送的参数：
\nsender未使用（总是 None）。
requestHttpRequest 对象。
只有当 运行测试 时才会发出信号。
\nsetting_changedLink to this heading#当通过 django.test.TestCase.settings() 上下文管理器或 django.test.override_settings() 装饰器／上下文管理器改变配置值时，会发出这个信号。
它实际上被发送了两次：当应用新的值时（"setup"）和当恢复原始值时（"drawdown"）。使用 enter 参数来区分这两种情况。
你也可以从 django.core.signals 导入这个信号，以避免在非测试情况下从 django.test 导入。
用此信号发送的参数：
\nsender配置处理程序。
\nsetting配置的名称。
\nvalue更改后的配置值。对于最初不存在的配置，在 "teardown" 阶段，value 是 None。
enter一个布尔值；True 如果配置被应用，False 如果恢复。
template_renderedLink to this heading#当测试系统渲染一个模板时发出。这个信号在 Django 服务器正常运行时不会发出，只有在测试时才会发出。
\n用此信号发送的参数：
\n\n当数据库连接启动时，数据库包装器发出的信号。
\nconnection_createdLink to this heading#Sent when the database wrapper makes the initial connection to the\ndatabase. This is particularly useful if you'd like to send any post\nconnection commands to the SQL backend.
\n用此信号发送的参数：
\nsender数据库封装类 —— 即 django.db.backends.postgresql.DatabaseWrapper 或 django.db.backends.mysql.DatabaseWrapper 等。
connection打开的数据库连接。这在多数据库配置中可以用来区分不同数据库的连接信号。
\nSignals sent by the tasks framework.
\ntask_enqueuedLink to this heading#Sent once a Task has been enqueued.
\n用此信号发送的参数：
\nsenderThe backend class which the Task was enqueued on to.
\ntask_resultThe enqueued TaskResult.
task_startedLink to this heading#Sent when a Task has started executing.
\n用此信号发送的参数：
\nsenderThe backend class which the Task was enqueued on to.
\ntask_resultThe started TaskResult.
task_finishedLink to this heading#Sent once a Task has finished executing, successfully or otherwise.
\n用此信号发送的参数：
\nsenderThe backend class which the Task was enqueued on to.
\ntask_resultThe finished TaskResult.