Une liste de tous les signaux envoyés par Django. Tous les signaux intégrés sont envoyés par la méthode send().
Le module django.db.models.signals définit un ensemble de signaux envoyés par le système des modèles.
pre_initLien vers cette rubrique#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 :
\nsenderLa classe de modèle dont une instance vient d’être créée.
\nargsUne liste de paramètres positionnels transmis à __init__().
kwargsUn dictionnaire de paramètres nommés transmis à __init__().
Par exemple, le tutoriel contient cette ligne :
\nq = Question(question_text="What's new?", pub_date=timezone.now())\nLes paramètres envoyés au gestionnaire pre_init sont :
Paramètre | \nValeur | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
post_initLien vers cette rubrique#Comme pre_init, mais celui-ci est envoyé lorsque la méthode __init__() se termine.
Paramètres envoyés avec ce signal :
\nsenderComme ci-dessus : la classe de modèle dont une instance vient d’être créée.
\ninstanceL’instance de modèle réelle qui vient d’être créée.
\n\npre_saveLien vers cette rubrique#Envoyé au début de la méthode save() d’un modèle.
Paramètres envoyés avec ce signal :
\nsenderLa classe de modèle.
\ninstanceL’instance réelle en cours d’enregistrement.
\nrawValeur booléenne ; 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.
usingL’alias de base de données utilisé.
\nupdate_fieldsLe groupe de champs à mettre à jour tel que transmis à la méthode Model.save(), ou None si update_fields n’a pas été transmis à save().
post_saveLien vers cette rubrique#Comme pre_save, mais envoyé à la fin de la méthode save().
Paramètres envoyés avec ce signal :
\nsenderLa classe de modèle.
\ninstanceL’instance réelle en cours d’enregistrement.
\ncreatedValeur booléenne ; True si un nouvel enregistrement a été créé.
rawValeur booléenne ; 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.
usingL’alias de base de données utilisé.
\nupdate_fieldsLe groupe de champs à mettre à jour tel que transmis à la méthode Model.save(), ou None si update_fields n’a pas été transmis à save().
pre_deleteLien vers cette rubrique#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 :
\nsenderLa classe de modèle.
\ninstanceL’instance réelle en cours de suppression.
\nusingL’alias de base de données utilisé.
\npost_deleteLien vers cette rubrique#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 :
\nsenderLa classe de modèle.
\ninstanceL’instance réelle en cours de suppression.
\nNotez 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.
\nusingL’alias de base de données utilisé.
\nm2m_changedLien vers cette rubrique#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 :
\nsenderLa classe de modèles intermédiaire déterminant le champ 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.
instanceL’instance dont la relation plusieurs-à-plusieurs est mise à jour. Cela peut être une instance de sender ou de la classe à laquelle est liée le champ ManyToManyField.
actionUne chaîne indiquant le type de mise à jour effectuée sur la relation. Voici les valeurs possibles :
\n"pre_add"Envoyé avant qu’un ou plusieurs objets soient ajoutés à la relation.
\n"post_add"Envoyé après qu’un ou plusieurs objets ont été ajoutés à la relation.
\n"pre_remove"Envoyé avant qu’un ou plusieurs objets soient supprimés de la relation.
\n"post_remove"Envoyé après qu’un ou plusieurs objets ont été supprimés de la relation.
\n"pre_clear"Envoyé avant que la relation soit effacée.
\n"post_clear"Envoyé après que la relation a été effacée.
\nreverseIndique quel côté de la relation est mis à jour (c’est-à-dire si c’est la relation directe ou inverse qui est en cours de modification).
\nmodelLa classe des objets qui sont ajoutés, supprimés ou retirés de la relation.
\npk_setPour 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.
usingL’alias de base de données utilisé.
\nPar exemple, si une Pizza peut comporter plusieurs objets Topping, selon ce modèle :
class Topping(models.Model):\n # ...\n pass\n\nclass Pizza(models.Model):\n # ...\n toppings = models.ManyToManyField(Topping)\nSi nous connectons un gestionnaire comme ceci :
\nfrom django.db.models.signals import m2m_changed\n\ndef toppings_changed(sender, **kwargs):\n # Do something\n pass\n\nm2m_changed.connect(toppings_changed, sender=Pizza.toppings.through)\npuis que nous faisons quelque chose comme ça :
\n>>> p = Pizza.objects.create(...)\n>>> t = Topping.objects.create(...)\n>>> p.toppings.add(t)\nles paramètres envoyés à un gestionnaire m2m_changed (toppings_changed dans l’exemple ci-dessus) seraient :
Paramètre | \nValeur | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
Et si nous faisions ensuite quelque chose comme ceci :
\n>>> t.pizza_set.remove(p)\nles paramètres envoyés à un gestionnaire m2m_changed seraient :
Paramètre | \nValeur | \n
|---|---|
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
| \n
class_preparedLien vers cette rubrique#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.
\nComme 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 :
\nsenderLa classe de modèle qui vient d’être préparée.
\nSignaux envoyés par django-admin.
\npre_migrateLien vers cette rubrique#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 :
\nsenderUne instance AppConfig de l’application sur le point d’être migrée/synchronisée.
app_configIdentique à sender.
verbosityIndique 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.
interactiveSi 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.
stdoutUn objet de type flux vers lequel sera redirigée la sortie verbeuse.
\nusingL’alias de base de données sur laquelle une commande va agir.
\nplanLe plan de migration qui sera utilisé pour l’exécution des migrations. Même si le plan ne fait pas partie de l’API publique, sa présence sert aux rares cas où il est nécessaire de connaître le plan. Un plan est une liste de tuples binaires avec le premier élément comme instance d’une classe de migration et le second élément indiquant si la migration a été défaite (True) ou appliquée (False).
appsUne instance de 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_migrateLien vers cette rubrique#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 :
\nsenderUne instance AppConfig de l’application qui vient d’être installée.
app_configIdentique à sender.
verbosityIndique 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.
interactiveSi 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.
stdoutUn objet de type flux vers lequel sera redirigée la sortie verbeuse.
\nusingL’alias de base de données utilisé pour la synchronisation. La valeur par défaut correspond à la base de données default.
planLe plan de migration utilisé pour l’exécution des migrations. Même si le plan ne fait pas partie de l’API publique, sa présence sert aux rares cas où il est nécessaire de connaître le plan. Un plan est une liste de tuples binaires avec le premier élément comme instance d’une classe de migration et le second élément indiquant si la migration a été défaite (True) ou appliquée (False).
appsUne instance de 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\nfrom django.db.models.signals import post_migrate\n\ndef my_callback(sender, **kwargs):\n # Your specific logic here\n pass\n\nclass MyAppConfig(AppConfig):\n ...\n\n def ready(self):\n post_migrate.connect(my_callback, sender=self)\nSignaux envoyés par le système de base lors du traitement d’une requête.
\nrequest_startedLien vers cette rubrique#Envoyé lorsque Django commence à traiter une requête HTTP.
\nParamètres envoyés avec ce signal :
\nsenderLa classe de gestion – par ex. django.core.handlers.wsgi.WsgiHandler – qui est chargée de la requête.
environLe dictionnaire environ fourni à la requête.
request_finishedLien vers cette rubrique#Envoyé lorsque Django a terminé l’envoi d’une réponse HTTP à un client.
\nParamètres envoyés avec ce signal :
\nsenderLa classe de gestion, comme ci-dessus.
\ngot_request_exceptionLien vers cette rubrique#Ce signal est envoyé chaque fois que Django rencontre une exception lors du traitement d’une requête HTTP entrante.
\nParamètres envoyés avec ce signal :
\nsenderInutilisé (toujours None).
requestL’objet HttpRequest.
Ces signaux ne sont envoyés que lors du fonctionnement des tests.
\nsetting_changedLien vers cette rubrique#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 :
\nsenderLe gestionnaire des réglages.
\nsettingLe nom du réglage.
\nvaleurLa valeur du réglage après la modification. Pour les réglages qui n’existent initialement pas, durant la phase de « teardown », value vaut None.
enterUne valeur booléenne ; True si le réglage doit être appliqué, False s’il doit être restauré.
template_renderedLien vers cette rubrique#Envoyé lorsque le système de test produit un gabarit. Ce signal n’est pas émis pendant les opérations normales d’un serveur Django, il n’est disponible que durant les tests.
\nParamètres envoyés avec ce signal :
\n\nSignaux envoyés par l’adaptateur de base de données lorsqu’une connexion à la base de données est initiée.
\nconnection_createdLien vers cette rubrique#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.
\nParamètres envoyés avec ce signal :
\nsenderLa classe d’adaptation de la base de données – c’est-à-dire django.db.backends.postgresql.DatabaseWrapper ou django.db.backends.mysql.DatabaseWrapper, etc.
connectionLa connexion de base de données qui a été ouverte. Cela peut être utilisé dans une configuration à plusieurs bases de données pour différencier les signaux de connexion de différentes bases de données.
\n