Сигналы¶

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, будут следующими:

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() и метода queryset delete().

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

sender

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

instance

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

using

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

origin

New in Django 4.1.

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

post_delete¶

django.db.models.signals.post_delete¶

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

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

sender

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

instance

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

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

using

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

origin

New in Django 4.1.

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

И если бы мы тогда сделали что-то вроде этого:

>>> t.pizza_set.remove(p)

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

class_prepared¶

django.db.models.signals.class_prepared¶

Sent whenever a model class has been «prepared» – that is, once a model has been defined and registered with Django’s model system. Django uses this signal internally; it’s not generally used in third-party applications.

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

New in Django 4.0.

Потокоподобный объект, куда должен быть перенаправлен подробный вывод.

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

New in Django 4.0.

Потокоподобный объект, куда должен быть перенаправлен подробный вывод.

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().

На самом деле он отправляется дважды: когда применяется новое значение («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

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