Сигналы

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

post_delete

django.db.models.signals.post_delete

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

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

sender

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

instance

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

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

using

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

origin

Экземпляр Model или QuerySet, инициировавший удаление, то есть экземпляр, для которого был вызван метод delete().

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

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

task_enqueued

django.tasks.signals.task_enqueued

Отправляется после постановки задачи в очередь.

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

sender

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

task_result

Поставленный в очередь объект TaskResult.

task_started

django.tasks.signals.task_started

Отправляется, когда начинается выполнение задачи.

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

sender

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

task_result

Запущенный объект TaskResult.

task_finished

django.tasks.signals.task_finished

Отправляется после завершения выполнения задачи, независимо от того, успешно оно прошло или нет.

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

sender

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

task_result

Завершенный объект TaskResult.