Сигналы

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

Смотрите также

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

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

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

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

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

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

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

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

Примечание

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

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

Аргумент Значение
sender Question (сам класс)
args [](пустой список, потому что не были переданы позиционные аргументы __init__())
kwargs {'question_text': "What's new?", 'pub_date': datetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=<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поскольку они будут выполняться для каждого экземпляра, возвращенного во время итерации набора запросов .

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
Используемый псевдоним базы данных.

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действий, это набор значений первичного ключа , которые будут, или были, добавляемых к соотношению. Это может быть подмножество значений, представленных для добавления, поскольку вставки должны фильтровать существующие значения во избежание создания базы данных IntegrityError.

Для pre_removeи post_removeдействий, это набор значений первичного ключа , который был представлен быть удален из соотношения. Это не зависит от того, действительно ли значения будут удалены или были удалены. В частности, могут быть отправлены несуществующие значения, и они появятся pk_set, даже если они не влияют на базу данных.

Для pre_clearи post_clearдействий, это None.

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

Например, если a 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.

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.

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экземпляра.

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

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

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

Copyright ©2021 All rights reserved