Сигналы

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

Новое в Django 1.10.

План миграции, который будет использоваться для выполнения миграции. Хотя план не является общедоступным API, это позволяет в редких случаях знать план. План — это список пар кортежей, где первый элемент — экземпляр класса миграции, а второй элемент показывает, была ли миграция отменена (True) или применена (False).

apps

Новое в Django 1.10.

Экземпляр 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

Новое в Django 1.10.

План миграции, который был использован для выполнения миграции. Хотя сам план не является частью публичного API, это позволяет в редких случаях получить доступ к плану. План представляет собой список пар «ключ-значение», где первый элемент — экземпляр класса миграции, а второй — информация о том, была ли миграция откатана (True) или применена (False).

apps

Новое в Django 1.10.

Экземпляр 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().

На самом деле он отправляется дважды: когда применяется новое значение («настройка») и когда восстанавливается исходное значение («разрушение»). Используйте аргумент 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

То же, что и sender

context

Объект Context, с помощью которого был отображен шаблон.

Оборачивающие компоненты баз данных

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

connection_created

django.db.backends.signals.connection_created

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

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

sender

Класс компонента базы данных – например, django.db.backends.postgresql.DatabaseWrapper или django.db.backends.mysql.DatabaseWrapper, и т. д.

connection

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