Сигналы ¶
Список всех сигналов, которые отправляет 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()
. AppConfig
s воссоздаются для тестов, которые выполняются с измененным набором 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
если восстановлена.
Оболочки базы данных ¶
Сигналы, отправляемые оболочкой базы данных при инициировании соединения с базой данных.
connection_created
¶
-
django.db.backends.signals.
connection_created
¶
Отправляется, когда оболочка базы данных устанавливает первоначальное соединение с базой данных. Это особенно полезно, если вы хотите отправлять какие-либо команды подключения к серверу SQL.
Аргументы, отправленные с этим сигналом:
sender
- Класс-оболочка базы данных - т.е.
django.db.backends.postgresql.DatabaseWrapper
илиdjango.db.backends.mysql.DatabaseWrapper
и т. Д. connection
- Открытое соединение с базой данных. Это можно использовать в конфигурации с несколькими базами данных, чтобы различать сигналы подключения от разных баз данных.