Сигналы

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

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

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

Начало обработки запроса

django.core.signals.request_started

Отправляется, когда Django начинает обработку HTTP-запроса.

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

sender

Класс обработчика — например, django.core.handlers.wsgi.WsgiHandler — который обработает запрос.

environ

Словарь environ , переданный в запрос.

Завершение обработки запроса

django.core.signals.request_finished

Отправляется, когда Django завершает передачу HTTP-ответа клиенту.

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

sender

Класс обработчика, как указано выше.

Исключение при обработке запроса

django.core.signals.got_request_exception

Этот сигнал отправляется всякий раз, когда Django обнаруживает исключение при обработке входящего HTTP-запроса.

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

sender

Класс обработчика, как указано выше.

request

Объект HttpRequest.

Сигналы для тестов

Сигналы, отправляемые только при выполнении тестов.

Изменение настроек

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 если восстановлена.

Отрендеренный шаблон

django.test.signals.template_rendered

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

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

sender

Объект Template, который был отрендерен.

template

То же, что и sender

context

Контекст Context, с которым был отрендерен шаблон.

Оборачивающие программы для баз данных

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

Соединение с базой данных создано

django.db.backends.signals.connection_created

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

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

sender

Класс оборачивающей программы базы данных — например, django.db.backends.postgresql.DatabaseWrapper или django.db.backends.mysql.DatabaseWrapper, и т. д.

connection

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