Une liste de tous les signaux envoyés par Django. Tous les signaux intégrés sont envoyés par la méthode send()
.
Voir aussi
Consultez la documentation sur la distribution de signaux pour plus d’informations sur la façon d’inscrire et de recevoir des signaux.
Le système d’authentification envoie des signaux lorsqu’un utilisateur se connecte ou se déconnecte.
Le module django.db.models.signals
définit un ensemble de signaux envoyés par le système des modèles.
Avertissement
Beaucoup de ces signaux sont envoyés par différentes méthodes de modèle comme __init__()
ou save()
. Ces méthodes peuvent être surchargées dans votre propre code.
Si vous surchargez ces méthodes dans un de vos modèles, vous devez appeler la méthode de la classe parente si vous voulez que les signaux soient envoyés.
Notez également que Django stocke les gestionnaires de signaux comme référence faible par défaut. Cela signifie que si le récepteur est une fonction locale, il peut être purgé de la mémoire. Pour empêcher cela, indiquez weak=False
lors de l’appel à la méthode connect()
du signal.
Note
Le modèle sender
des signaux de modèles peut être référencé de manière différée lors de la connexion à un récepteur en indiquant son étiquette d’application complète. Par exemple, un modèle Question
défini dans l’application polls
peut être référencé en tant que 'polls.Question'
. Ce type de référence peut être bien pratique lorsqu’on est confronté à des dépendances d’importation circulaire ou à des modèles interchangeables.
pre_init
¶django.db.models.signals.
pre_init
¶Lors de chaque instanciation d’un modèle Django, ce signal est envoyé au début de la méthode __init__()
du modèle.
Paramètres envoyés avec ce signal :
sender
args
__init__()
.kwargs
__init__()
.Par exemple, le tutoriel contient cette ligne :
q = Question(question_text="What's new?", pub_date=timezone.now())
Les paramètres envoyés au gestionnaire pre_init
sont :
Paramètre | Valeur |
---|---|
sender |
Question (la classe elle-même) |
args |
[] (une liste vide, car aucun paramètre positionnel n’a été transmis à __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
¶Comme pre_init
, mais celui-ci est envoyé lorsque la méthode __init__()
se termine.
Paramètres envoyés avec ce signal :
sender
instance
L’instance de modèle réelle qui vient d’être créée.
Note
instance._state
n’est pas défini avant l’envoi du signal post_init
, ce qui fait que les attributs _state
ont toujours leurs valeurs par défaut. Par exemple, _state.db
vaut None
.
Avertissement
Pour des raisons de performance, vous ne devriez pas exécuter de requête dans les récepteurs des signaux pre_init
ou post_init
parce qu’elles seraient exécutées pour chaque instance renvoyée durant une itération d’un jeu de requête.
pre_save
¶django.db.models.signals.
pre_save
¶Envoyé au début de la méthode save()
d’un modèle.
Paramètres envoyés avec ce signal :
sender
instance
raw
True
si le modèle est enregistré exactement comme présenté (par ex. lors du chargement d’un instantané). Il ne faut pas interroger ou modifier d’autres enregistrements de la base de données, car celle-ci pourrait se trouver provisoirement dans un état non cohérent.using
update_fields
Model.save()
, ou None
si update_fields
n’a pas été transmis à save()
.post_save
¶django.db.models.signals.
post_save
¶Comme pre_save
, mais envoyé à la fin de la méthode save()
.
Paramètres envoyés avec ce signal :
sender
instance
created
True
si un nouvel enregistrement a été créé.raw
True
si le modèle est enregistré exactement comme présenté (par ex. lors du chargement d’un instantané). Il ne faut pas interroger ou modifier d’autres enregistrements de la base de données, car celle-ci pourrait se trouver provisoirement dans un état non cohérent.using
update_fields
Model.save()
, ou None
si update_fields
n’a pas été transmis à save()
.pre_delete
¶django.db.models.signals.
pre_delete
¶Envoyé au début de la méthode delete()
d’un modèle ou de la méthode delete()
d’un QuerySet
.
Paramètres envoyés avec ce signal :
sender
instance
using
post_delete
¶django.db.models.signals.
post_delete
¶Comme pre_delete
, mais envoyé à la fin de la méthode delete()
d’un modèle ou de la méthode delete()
d’un QuerySet
.
Paramètres envoyés avec ce signal :
sender
instance
L’instance réelle en cours de suppression.
Notez que l’objet ne se trouve plus dans la base de données, soyez donc très prudent avec ce que vous faites de cette instance.
using
m2m_changed
¶django.db.models.signals.
m2m_changed
¶Envoyé lorsqu’un champ ManyToManyField
est modifié dans une instance de modèle. Strictement parlant, il ne s’agit pas d’un signal de modèle car il est envoyé par ManyToManyField
, mais comme il complète les signaux pre_save
/post_save
et pre_delete
/post_delete
en ce qui concerne le suivi des modifications des modèles, nous l’avons inclus sous cette rubrique.
Paramètres envoyés avec ce signal :
sender
ManyToManyField
. Cette classe est automatiquement créée lors de la définition d’un champ plusieurs-à-plusieurs ; vous pouvez y accéder par l’attribut through
du champ plusieurs-à-plusieurs.instance
sender
ou de la classe à laquelle est liée le champ ManyToManyField
.action
Une chaîne indiquant le type de mise à jour effectuée sur la relation. Voici les valeurs possibles :
"pre_add"
"post_add"
"pre_remove"
"post_remove"
"pre_clear"
"post_clear"
reverse
model
pk_set
Pour les actions pre_add
et post_add
, il s’agit d’un ensemble de clés primaires qui seront ou ont été ajoutées à la relation. Il peut s’agir d’un sous-ensemble des valeurs soumises pour l’ajout, car les insertions doivent filtrer les valeurs existantes afin d’éviter les erreurs de base de données IntegrityError
.
Pour les actions pre_remove
et post_remove
, il s’agit d’un ensemble de clés primaires qui ont été soumises pour la suppression de la relation. Ces valeurs ne dépendent pas du succès ou non de leur réelle suppression. En particulier, des valeurs inexistantes peuvent être soumises et apparaître donc dans pk_set
, même si elles n’auront aucun effet sur la base de données.
Pour les signaux pre_clear
et post_clear
actions, cette valeur vaut None
.
using
Par exemple, si une Pizza
peut comporter plusieurs objets Topping
, selon ce modèle :
class Topping(models.Model):
# ...
pass
class Pizza(models.Model):
# ...
toppings = models.ManyToManyField(Topping)
Si nous connectons un gestionnaire comme ceci :
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)
puis que nous faisons quelque chose comme ça :
>>> p = Pizza.objects.create(...)
>>> t = Topping.objects.create(...)
>>> p.toppings.add(t)
les paramètres envoyés à un gestionnaire m2m_changed
(toppings_changed
dans l’exemple ci-dessus) seraient :
Paramètre | Valeur |
---|---|
sender |
Pizza.toppings.through (la classe plusieurs-à-plusieurs intermédiaire) |
instance |
p (l’instance Pizza en cours de modification) |
action |
"pre_add" (suivi d’un autre signal avec "post_add" ) |
reverse |
False (Pizza contient le champ ManyToManyField , ce qui fait que cette fonction modifie la relation directe) |
model |
Topping (la classe des objets ajoutés à Pizza ) |
pk_set |
{t.id} (car seul Topping t a été ajouté à la relation) |
using |
"default" (parce que le routeur par défaut dirige les écritures à cette destination) |
Et si nous faisions ensuite quelque chose comme ceci :
>>> t.pizza_set.remove(p)
les paramètres envoyés à un gestionnaire m2m_changed
seraient :
Paramètre | Valeur |
---|---|
sender |
Pizza.toppings.through (la classe plusieurs-à-plusieurs intermédiaire) |
instance |
t (l’instance Topping en cours de modification) |
action |
"pre_remove" (suivi d’un autre signal avec "post_remove" ) |
reverse |
True (c’est Pizza qui contient le champ ManyToManyField , ce qui fait que cette fonction modifie la relation inverse) |
model |
Pizza (la classe des objets retirés de Topping ) |
pk_set |
{p.id} (car seul Pizza p a été enlevé de la relation) |
using |
"default" (parce que le routeur par défaut dirige les écritures à cette destination) |
class_prepared
¶django.db.models.signals.
class_prepared
¶Envoyé chaque fois qu’une classe de modèle a été « préparée », c’est-à-dire après que le modèle a été défini et inscrit dans le système des modèles de Django. Django utilise ce signal en interne ; il n’est généralement pas utilisé dans des applications tierces.
Comme ce signal est envoyé durant le processus de remplissage du registre des applications et que AppConfig.ready()
s’exécute après la fin de ce remplissage, les récepteurs ne peuvent pas être connectés dans cette méthode. Une possibilité est de les connecter dans AppConfig.__init__()
en prenant soi de ne pas importer de modèles ni de déclencher des appels au registre des applications.
Paramètres envoyés avec ce signal :
sender
Signaux envoyés par django-admin.
pre_migrate
¶django.db.models.signals.
pre_migrate
¶Envoyé par la commande migrate
afin le début de l’installation d’une application. Il n’est pas émis pour les applications qui n’ont pas de module models
.
Paramètres envoyés avec ce signal :
sender
AppConfig
de l’application sur le point d’être migrée/synchronisée.app_config
sender
.verbosity
Indique la quantité d’informations que manage.py
affiche à l’écran. Voir l’option --verbosity
pour plus de détails.
Les fonctions à l’écoute de pre_migrate
devraient ajuster ce qu’elles affichent en fonction de la valeur de ce paramètre.
interactive
Si interactive
vaut True
, il est tout à fait possible de demander à l’utilisateur de saisir des informations sur la ligne de commande. Si interactive
vaut False
, les fonctions à l’écoute de ce signal ne doivent pas du tout interroger l’utilisateur.
Par exemple, l’application django.contrib.auth
ne demande les informations de création du super-utilisateur que lorsqu”interactive
vaut True
.
using
plan
True
) ou appliquée (False
).apps
Apps
contenant l’état du projet avant l’exécution des migrations. Elle devrait être utilisée en lieu et place du registre global apps
pour récupérer les modèles sur lesquels portent les opérations.post_migrate
¶django.db.models.signals.
post_migrate
¶Envoyé à la fin des commandes migrate
(même si aucune migration n’est effectuée) et flush
. Il n’est pas émis pour les applications qui ne possèdent pas de module models
.
Les gestionnaires de ce signal ne doivent pas effectuer de modification de base de données car cela pourrait provoquer l’échec de la commande d’administration flush
si elle s’exécute pendant la commande migrate
.
Paramètres envoyés avec ce signal :
sender
AppConfig
de l’application qui vient d’être installée.app_config
sender
.verbosity
Indique la quantité d’informations que manage.py
affiche à l’écran. Voir l’option --verbosity
pour plus de détails.
Les fonctions à l’écoute de post_migrate
devraient ajuster ce qu’elles affichent en fonction de la valeur de ce paramètre.
interactive
Si interactive
vaut True
, il est tout à fait possible de demander à l’utilisateur de saisir des informations sur la ligne de commande. Si interactive
vaut False
, les fonctions à l’écoute de ce signal ne doivent pas du tout interroger l’utilisateur.
Par exemple, l’application django.contrib.auth
ne demande les informations de création du super-utilisateur que lorsqu”interactive
vaut True
.
using
default
.plan
True
) ou appliquée (False
).apps
Apps
contenant l’état du projet après l’exécution des migrations. Elle devrait être utilisée en lieu et place du registre global apps
pour récupérer les modèles sur lesquels portent les opérations.Par exemple, il est possible d’inscrire une fonction de rappel dans une classe AppConfig
comme ceci :
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)
Note
Si vous fournissez une instance AppConfig
comme paramètre sender
, contrôlez bien que le signal est inscrit dans la méthode ready()
. Des instances AppConfig
sont recréées pour les tests qui fonctionnent avec un réglage INSTALLED_APPS
modifié (comme quand les réglages sont temporairement surchargés) et de tels signaux doivent alors être connectés pour chaque nouvelle instance de AppConfig
.
Signaux envoyés par le système de base lors du traitement d’une requête.
request_started
¶django.core.signals.
request_started
¶Envoyé lorsque Django commence à traiter une requête HTTP.
Paramètres envoyés avec ce signal :
sender
django.core.handlers.wsgi.WsgiHandler
– qui est chargée de la requête.environ
environ
fourni à la requête.request_finished
¶django.core.signals.
request_finished
¶Envoyé lorsque Django a terminé l’envoi d’une réponse HTTP à un client.
Paramètres envoyés avec ce signal :
sender
got_request_exception
¶django.core.signals.
got_request_exception
¶Ce signal est envoyé chaque fois que Django rencontre une exception lors du traitement d’une requête HTTP entrante.
Paramètres envoyés avec ce signal :
sender
None
).request
HttpRequest
.Ces signaux ne sont envoyés que lors du fonctionnement des tests.
setting_changed
¶django.test.signals.
setting_changed
¶Ce signal est envoyé lorsque la valeur d’un réglage a été modifiée par le gestionnaire de contexte django.test.TestCase.settings()
ou le décorateur/gestionnaire de contexte django.test.override_settings()
.
En fait, il est envoyé deux fois : lorsque la nouvelle valeur est appliquée (« setup ») et lorsque la valeur originale est restaurée (« teardown »). Utilisez le paramètre enter
pour distinguer entre les deux cas.
Vous pouvez aussi importer ce signal à partir de django.core.signals
pour éviter de l’importer à partir de django.test
dans un contexte ne concernant pas les tests.
Paramètres envoyés avec ce signal :
sender
setting
valeur
value
vaut None
.enter
True
si le réglage doit être appliqué, False
s’il doit être restauré.Signaux envoyés par l’adaptateur de base de données lorsqu’une connexion à la base de données est initiée.
connection_created
¶django.db.backends.signals.
connection_created
¶Envoyé lorsque l’adaptateur de base de données crée la connexion initiale à la base de données. C’est particulièrement utile si vous avez besoin d’envoyer des commandes post connexion au moteur SQL.
Paramètres envoyés avec ce signal :
sender
django.db.backends.postgresql.DatabaseWrapper
ou django.db.backends.mysql.DatabaseWrapper
, etc.connection
déc. 07, 2021