Сигналы

Список всех сигналов, которые посылает Django. Все встроенные сигналы отправляются с помощью метода send().

См.также

См. документацию на signal dispatcher для получения информации о том, как регистрировать и принимать сигналы.

authentication framework посылает signals when a user is logged in / out.

Модельные сигналы

Модуль django.db.models.signals определяет набор сигналов, посылаемых модельной системой.

Предупреждение

Сигналы могут усложнить сопровождение вашего кода. Рассмотрите возможность реализации вспомогательного метода на custom manager, чтобы обновлять модели и выполнять дополнительную логику, или overriding model methods перед использованием сигналов модели.

Предупреждение

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

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

Обратите внимание, что Django по умолчанию хранит обработчики сигналов как слабые ссылки, поэтому если ваш обработчик является локальной функцией, он может быть собран в мусор. Чтобы предотвратить это, передавайте weak=False при вызове connect() сигнала.

Примечание

На сигналы модели sender модели можно лениво ссылаться при подключении приемника, указывая его полную метку приложения. Например, на модель Question, определенную в приложении polls, можно сослаться как на 'polls.Question'. Такой вид ссылки может быть весьма удобен при работе с круговыми зависимостями импорта и заменяемыми моделями.

pre_init

django.db.models.signals.pre_init

Когда вы инстанцируете модель Django, этот сигнал посылается в начале метода модели __init__().

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

sender
Класс модели, экземпляр которого только что был создан.
args
Список позиционных аргументов, передаваемых в __init__().
kwargs
Словарь аргументов ключевых слов, переданных в __init__().

Например, в tutorial есть такая строка:

q = Question(question_text="What's new?", pub_date=timezone.now())

Аргументы, передаваемые обработчику pre_init, будут следующими:

Аргумент Значение
sender Question (сам класс)
args [] (пустой список, поскольку не было передано позиционных аргументов для __init__())
kwargs {'question_text': "What's new?", 'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.timezone.utc)}

post_init

django.db.models.signals.post_init

Подобно pre_init, но этот отправляется, когда завершается метод __init__().

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

sender
Как и выше: класс модели, у которого только что был создан экземпляр.
instance

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

Примечание

instance._state не устанавливается перед отправкой сигнала post_init, поэтому атрибуты _state всегда имеют значения по умолчанию. Например, _state.db - это None.

Предупреждение

По соображениям производительности не следует выполнять запросы в приемниках сигналов pre_init или post_init, поскольку они будут выполняться для каждого экземпляра, возвращаемого во время итерации queryset.

pre_save

django.db.models.signals.pre_save

Это сообщение отправляется в начале метода модели save().

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

sender
Класс модели.
instance
Фактический сохраняемый экземпляр.
raw
Булево значение; True, если модель сохраняется именно в том виде, в котором она представлена (т.е. при загрузке fixture). Не следует запрашивать/изменять другие записи в базе данных, так как база данных может быть еще не в согласованном состоянии.
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, если модель сохраняется именно в том виде, в котором она представлена (т.е. при загрузке fixture). Не следует запрашивать/изменять другие записи в базе данных, так как база данных может быть еще не в согласованном состоянии.
using
Используемый псевдоним базы данных.
update_fields
Набор полей для обновления, переданный в Model.save(), или None, если update_fields не был передан в save().

pre_delete

django.db.models.signals.pre_delete

Отправляется в начале метода модели delete() и метода queryset delete().

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

sender
Класс модели.
instance
Фактический экземпляр, который удаляется.
using
Используемый псевдоним базы данных.

origin

templates.E003:Model используется для нескольких модулей тегов шаблонов: QuerySet.

post_delete

django.db.models.signals.post_delete

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

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

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

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

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

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

origin

templates.E003: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 это post_clear.

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 в примере выше), будут такими:

Аргумент Значение
sender Pizza.toppings.through (промежуточный класс m2m)
instance p (модифицируемый экземпляр Pizza)
action "pre_add" (за ним следует отдельный сигнал "post_add")
reverse False (Pizza содержит ManyToManyField, поэтому этот вызов изменяет прямое отношение)
model Topping (класс объектов, добавленных в Pizza)
pk_set {t.id} (так как к отношению было добавлено только Topping t)
using "default" (так как маршрутизатор по умолчанию отправляет сюда записи)

И если бы мы тогда сделали что-то подобное:

>>> t.pizza_set.remove(p)

аргументы, передаваемые обработчику m2m_changed, будут такими:

Аргумент Значение
sender Pizza.toppings.through (промежуточный класс m2m)
instance t (модифицируемый экземпляр Topping)
action "pre_remove" (за ним следует отдельный сигнал "post_remove")
reverse True (Pizza содержит ManyToManyField, поэтому этот вызов изменяет обратное отношение)
model Pizza (класс объектов, удаленных из Topping)
pk_set {p.id} (так как из отношения было удалено только Pizza p)
using "default" (так как маршрутизатор по умолчанию отправляет сюда записи)

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)

Примечание

Если вы предоставляете экземпляр AppConfig в качестве аргумента отправителя, убедитесь, что сигнал зарегистрирован в ready(). AppConfigs создаются заново для тестов, которые выполняются с измененным набором INSTALLED_APPS (например, когда переопределяются настройки), и такие сигналы должны быть подключены для каждого нового AppConfig экземпляра.

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

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

Предупреждение

Сигналы могут усложнить сопровождение вашего кода. Прежде чем использовать сигналы запроса/ответа, подумайте о using a middleware.

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.

Тестовые сигналы

Сигналы посылаются только тогда, когда running tests.

setting_changed

django.test.signals.setting_changed

Этот сигнал посылается при изменении значения параметра через менеджер контекста django.test.TestCase.settings() или менеджер декоратора/контекста django.test.override_settings().

На самом деле он отправляется дважды: когда применяется новое значение («setup») и когда восстанавливается исходное значение («teardown»). Используйте аргумент 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
Соединение с базой данных, которое было открыто. Это можно использовать в конфигурации с несколькими базами данных, чтобы различать сигналы подключения от разных баз данных.
Вернуться на верх