Сигналы

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

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

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

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, будут:

post_init

django.db.models.signals.post_init

Аналогично pre_init, но этот сигнал отправляется, когда метод __init__() завершает работу.

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

sender

Как и выше: класс модели, у которой только что был создан экземпляр.

instance

Фактический экземпляр модели, который только что был создан.

Примечание

instance._state не задается перед отправкой сигнала post_init, поэтому атрибуты _state всегда имеют свои значения по умолчанию. Например, _state.db имеет значение None.

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

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

origin

post_delete

django.db.models.signals.post_delete

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

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

sender

Класс модели.

instance

Фактический удаляемый экземпляр.

Обратите внимание, что объект больше не будет находиться в базе данных, поэтому будьте осторожны с тем, что вы делаете с этим экземпляром.

using

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

origin

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 в приведённом примере) будут:

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

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

stdout

Объект потокового типа, куда следует перенаправить подробный вывод.

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.

stdout

Потокоподобный объект, куда должен быть перенаправлен подробный вывод.

using

Псевдоним базы данных, используемый для синхронизации. По умолчанию используется база данных default.

plan

План миграции, который использовался для выполнения миграции. Хотя план не является частью публичного API, это позволяет в редких случаях узнать план. План представляет собой список пар 2-кортежей, где первый элемент — экземпляр класса миграции, а второй элемент — информация о том, была ли миграция отменена (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

Не используется (всегда 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

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

value

Значение настройки после изменения. Для настроек, которых изначально не существует, в фазе «разборка» value равно None.

enter

Булево значение; True если настройка применяется, False если восстанавливается.

template_rendered

django.test.signals.template_rendered

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

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

sender

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

template

То же, что и отправитель

context

Объект Context, с которым был рендерирован шаблон.

Оборачиватели баз данных

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

connection_created

django.db.backends.signals.connection_created

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

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

sender

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

connection

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