Сигналы

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

Новое в Django 4.1.

Источник удаления — экземпляр класса Model или QuerySet.

post_delete

django.db.models.signals.post_delete

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

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

sender

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

instance

Удалимый экземпляр.

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

using

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

origin

Новое в Django 4.1.

Источник удаления — экземпляр класса Model или QuerySet.

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

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