Сигналы ¶
Список всех сигналов, отправленных Django. Все интегрированные сигналы отправляются методом send()
.
Смотрите также
См. Документацию по распределению сигналов для получения дополнительной информации о том, как регистрировать и получать сигналы.
Система аутентификации отправляет сигналы, когда пользователь входит в систему или выходит из нее .
Сигналы модели ¶
Модуль django.db.models.signals
определяет набор сигналов, посылаемых модельной системой.
Предупреждение
Многие из этих сигналов отправляются различными методами шаблона, такими как __init__()
или save()
. Эти методы можно переопределить в вашем собственном коде.
Если вы переопределите эти методы в одной из своих моделей, вы должны вызвать метод родительского класса, если хотите, чтобы сигналы отправлялись.
Также обратите внимание, что Django по умолчанию хранит обработчики сигналов как слабые ссылки. Это означает, что если приемник является локальной функцией, его можно очистить из памяти. Чтобы этого не weak=False
произошло , укажите при вызове метода connect()
сигнала.
Заметка
На шаблон шаблонных sender
сигналов можно отложить ссылку при подключении к приемнику, указав его полную метку приложения. Например, модель, Question
определенная в приложении, polls
может обозначаться как 'polls.Question'
. Этот тип справочника может пригодиться при работе с зависимостями циклического импорта или взаимозаменяемыми моделями.
pre_init
¶
-
django.db.models.signals.
pre_init
¶
Каждый раз, когда создается модель Django, этот сигнал отправляется в начале метода __init__()
модели.
Параметры, отправленные с этим сигналом:
sender
- Класс модели, экземпляр которого только что был создан.
args
- Список переданных позиционных параметров
__init__()
. kwargs
- Словарь переданных именованных параметров
__init__()
.
Например, в руководстве есть такая строка:
q = Question(question_text="What's new?", pub_date=timezone.now())
Параметры, отправленные менеджеру pre_init
:
настройка | Стоимость |
---|---|
sender |
Question (сам класс) |
args |
[] (пустой список, потому что не был передан позиционный параметр __init__() ) |
kwargs |
{'question_text': "What's new?",
'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<UTC>)} |
post_init
¶
-
django.db.models.signals.
post_init
¶
Вроде pre_init
, но этот отправляется, когда метод __init__()
заканчивается.
Параметры, отправленные с этим сигналом:
sender
- Как указано выше: класс модели, экземпляр которого только что был создан.
instance
Фактический экземпляр модели, который только что был создан.
Заметка
instance._state
не устанавливается перед отправкой сигналаpost_init
, поэтому атрибуты_state
всегда имеют значения по умолчанию. Например,_state.db
стоитNone
.
Предупреждение
По соображениям производительности не следует запускать запросы к приемникам сигналов pre_init
или post_init
потому, что они будут выполняться для каждого экземпляра, возвращаемого во время итерации набора запросов.
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()
или метода QuerySet
.
Параметры, отправленные с этим сигналом:
sender
- Класс модели.
instance
- Фактический удаляемый экземпляр.
using
- Используемый псевдоним базы данных.
post_delete
¶
-
django.db.models.signals.
post_delete
¶
Подобно pre_delete
, но отправляется в конце метода delete()
модели delete()
или метода QuerySet
.
Параметры, отправленные с этим сигналом:
sender
- Класс модели.
instance
Фактический удаляемый экземпляр.
Обратите внимание, что объекта больше нет в базе данных, поэтому будьте очень осторожны с тем, что вы делаете с этим экземпляром.
using
- Используемый псевдоним базы данных.
m2m_changed
¶
-
django.db.models.signals.
m2m_changed
¶
Отправляется при изменении поля ManyToManyField
в экземпляре шаблона. Строго говоря, это не сигнал модели в том виде, в каком он отправляется 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
это набор первичных ключей, которые будут или были добавлены в отношения. Это может быть подмножество значений, отправленных для добавления, поскольку вставки должны отфильтровывать существующие значения, чтобы избежать ошибок базы данных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
в приведенном выше примере), будут:
настройка | Стоимость |
---|---|
sender |
Pizza.toppings.through (промежуточный класс "многие ко многим") |
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 (промежуточный класс "многие ко многим") |
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 использует этот сигнал для внутренних целей; обычно он не используется в сторонних приложениях.
Поскольку этот сигнал отправляется в процессе заполнения регистра приложения и AppConfig.ready()
выполняется после завершения этого заполнения, приемники не могут быть подключены в этом методе. Одна из возможностей состоит в том, чтобы соединить их так, AppConfig.__init__()
чтобы не импортировать модели и не запускать вызовы реестра приложений.
Параметры, отправленные с этим сигналом:
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
:
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
.
Сигналы запроса и ответа ¶
Сигналы, отправленные базовой системой при обработке запроса.
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
- Не используется (все еще
None
). 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
- Название настройки.
valeur
- Значение настройки после изменения. Для параметров , которые изначально не существуют, во время фазы «» демонтажа, является
value
действительнымNone
. enter
- Логическое значение;
True
следует ли применять настройку, нужноFalse
ли ее восстанавливать.
Адаптеры баз данных ¶
Сигналы, отправляемые адаптером базы данных при инициировании соединения с базой данных.
connection_created
¶
-
django.db.backends.signals.
connection_created
¶
Отправляется, когда адаптер базы данных создает начальное соединение с базой данных. Это особенно полезно, если вам нужно отправить команды после входа в систему SQL.
Параметры, отправленные с этим сигналом:
sender
- Класс адаптации базы данных - т.е.
django.db.backends.postgresql.DatabaseWrapper
илиdjango.db.backends.mysql.DatabaseWrapper
и т. Д. connection
- Открытое соединение с базой данных. Это можно использовать в конфигурации с несколькими базами данных, чтобы различать сигналы подключения от разных баз данных.