Сигналы

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

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

post_delete

django.db.models.signals.post_delete

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

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

sender

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

instance

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

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

using

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

origin

Источник удаления — экземпляр класса 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

Класс модели, который был только что подготовлен.

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

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