Сигналы

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

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

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

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

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

То же, что и sender

context

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

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

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

connection_created

django.db.backends.signals.connection_created

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

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

sender

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

connection

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