Сигналы

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

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

Модуль 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

Множество полей, явно указанных для обновления в методе save(). None если этот аргумент не был использован в вызове save().

post_save

django.db.models.signals.post_save

Как pre_save, но отправляется в конце метода save().

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

sender

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

instance

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

created

Булево значение; True если была создана новая запись.

raw

Булево значение; True если модель сохраняется точно так, как представлена (например, при загрузке фикстуры). Не следует выполнять запросы/модификации других записей в базе данных, так как база данных может еще не быть в согласованном состоянии.

using

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

update_fields

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

Алиас базы данных, к которой будет обращаться команда.

pre_syncdb

django.db.models.signals.pre_syncdb

Отправляется командой syncdb перед началом установки приложения.

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

sender

Модуль models, который был только что установлен. То есть, если syncdb только что установил приложение "foo.bar.myapp", sender будет модулем foo.bar.myapp.models.

app

То же, что и sender.

create_models

Список классов моделей из любого приложения, которое syncdb планирует создать.

verbosity

Указывает, сколько информации будет выведено manage.py на экран. Подробнее см. флаг --verbosity.

Функции, подключающиеся к pre_syncdb, должны корректировать вывод на экран в зависимости от значения этого аргумента.

interactive

Если interactive равно True, можно безопасно запросить у пользователя ввод с командной строки. Если interactive равно False, функции, подключающиеся к этому сигналу, не должны пытаться запросить что-либо.

Например, приложение django.contrib.auth запрашивает создание суперпользователя только тогда, когда interactive равно True.

db

Алиас базы данных, к которой будет обращаться команда.

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.

Например, вы можете зарегистрировать обратный вызов в 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)

post_syncdb

django.db.models.signals.post_syncdb

Отправляется командой syncdb после установки приложения и командой flush.

Обработчики этого сигнала должны выполнять идемпотентные изменения (например, без изменений в базе данных), поскольку это может привести к ошибке команды управления flush, если она также была запущена во время выполнения команды syncdb.

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

sender

Модуль models , который только что был установлен. То есть, если syncdb только что установила приложение с именем "foo.bar.myapp", sender будет модулем foo.bar.myapp.models.

app

То же, что и sender.

created_models

Список классов моделей из любого приложения, которое syncdb создало до этого момента.

verbosity

Указывает, сколько информации manage.py выводит на экран. Подробности см. в флаге --verbosity.

Функции, которые слушают post_syncdb, должны изменять вывод на экран в зависимости от значения этого аргумента.

interactive

Если interactive равно True, можно безопасно запросить у пользователя ввод с командной строки. Если interactive равно False, функции, которые слушают этот сигнал, не должны пытаться запросить ничего.

Например, приложение django.contrib.auth запрашивает создание суперпользователя только при interactive равном True.

db

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

Например, yourapp/management/__init__.py можно написать так:

from django.db.models.signals import post_syncdb
import yourapp.models

def my_callback(sender, **kwargs):
    # Your specific logic here
    pass

post_syncdb.connect(my_callback, sender=yourapp.models)

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

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

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

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

context

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

Обёртки для баз данных

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

connection_created

django.db.backends.signals.connection_created

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

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

sender

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

connection

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