Сигналы

Список всех сигналов, отправленных 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 ли ее восстанавливать.

template_rendered

django.test.signals.template_rendered

Отправляется, когда тестовая система создает шаблон. Этот сигнал не излучается во время нормальной работы сервера Django, он доступен только во время тестирования.

Параметры, отправленные с этим сигналом:

sender
Созданный объект Template .
template
Похожий на sender
context
Объект, Context с которым был создан шаблон.

Адаптеры баз данных

Сигналы, отправляемые адаптером базы данных при инициировании соединения с базой данных.

connection_created

django.db.backends.signals.connection_created

Отправляется, когда адаптер базы данных создает начальное соединение с базой данных. Это особенно полезно, если вам нужно отправить команды после входа в систему SQL.

Параметры, отправленные с этим сигналом:

sender
Класс адаптации базы данных - т.е. django.db.backends.postgresql.DatabaseWrapper или django.db.backends.mysql.DatabaseWrapper и т. Д.
connection
Открытое соединение с базой данных. Это можно использовать в конфигурации с несколькими базами данных, чтобы различать сигналы подключения от разных баз данных.

Copyright ©2021 All rights reserved