Сигналы

Список всех сигналов, которые отправляет Django. Все встроенные сигналы отправляются с помощью метода send().

Сигналы моделей

Модуль django.db.models.signals определяет набор сигналов, отправляемых системой моделей.

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, будут такими:

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

Используемый псевдоним базы данных.

post_delete

django.db.models.signals.post_delete

Как и pre_delete, но отправляется в конце метода delete() модели и метода delete() набора запросов.

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

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, pre_remove и post_remove, это набор значений первичных ключей, которые были добавлены или удалены из связи.

Для действий 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 в примере выше), будут следующими:

И если бы мы затем сделали что-то вроде этого:

>>> t.pizza_set.remove(p)

аргументы, отправленные обработчику m2m_changed, были бы:

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)

Сигналы запроса/ответа

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

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().

Он отправляется дважды: когда новое значение применяется («setup») и когда исходное значение восстанавливается («teardown»). Используйте аргумент enter для различения этих двух случаев.

Вы также можете импортировать этот сигнал из django.core.signals, чтобы избежать импорта из django.test в ситуациях, не связанных с тестированием.

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

sender

Обработчик настроек.

setting

Имя настройки.

value

Значение настройки после изменения. Для настроек, которые изначально не существовали, в фазе «teardown» 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

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