SignauxLien vers cette rubrique#

pre_initLien vers cette rubrique#

django.db.models.signals.pre_initLien vers cette définition#

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

La classe de modèle dont une instance vient d’être créée.

args

Une liste de paramètres positionnels transmis à __init__().

kwargs

Un dictionnaire de paramètres nommés transmis à __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 :

post_initLien vers cette rubrique#

django.db.models.signals.post_initLien vers cette définition#

Comme pre_init, mais celui-ci est envoyé lorsque la méthode __init__() se termine.

Paramètres envoyés avec ce signal :

sender

Comme ci-dessus : la classe de modèle dont une instance vient d’être créée.

instance

L’instance de modèle réelle qui vient d’être créée.

pre_saveLien vers cette rubrique#

django.db.models.signals.pre_saveLien vers cette définition#

Envoyé au début de la méthode save() d’un modèle.

Paramètres envoyés avec ce signal :

sender

La classe de modèle.

instance

L’instance réelle en cours d’enregistrement.

raw

Valeur 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.

using

L’alias de base de données utilisé.

update_fields

Le 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#

django.db.models.signals.post_saveLien vers cette définition#

Comme pre_save, mais envoyé à la fin de la méthode save().

Paramètres envoyés avec ce signal :

sender

La classe de modèle.

instance

L’instance réelle en cours d’enregistrement.

created

Valeur booléenne ; True si un nouvel enregistrement a été créé.

raw

Valeur 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.

using

L’alias de base de données utilisé.

update_fields

Le 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#

django.db.models.signals.pre_deleteLien vers cette définition#

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

La classe de modèle.

instance

L’instance réelle en cours de suppression.

using

L’alias de base de données utilisé.

origin

L’instance Model ou QuerySet de l’origine de la suppression, c’est-à-dire l’instance sur laquelle la méthode delete() a été appelée.

post_deleteLien vers cette rubrique#

django.db.models.signals.post_deleteLien vers cette définition#

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

La classe de modèle.

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

L’alias de base de données utilisé.

origin

L’instance Model ou QuerySet de l’origine de la suppression, c’est-à-dire l’instance sur laquelle la méthode delete() a été appelée.

m2m_changedLien vers cette rubrique#

django.db.models.signals.m2m_changedLien vers cette définition#

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

La 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.

instance

L’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.

action

Une chaîne indiquant le type de mise à jour effectuée sur la relation. Voici les valeurs possibles :

"pre_add"

Envoyé avant qu’un ou plusieurs objets soient ajoutés à la relation.

"post_add"

Envoyé après qu’un ou plusieurs objets ont été ajoutés à la relation.

"pre_remove"

Envoyé avant qu’un ou plusieurs objets soient supprimés de la relation.

"post_remove"

Envoyé après qu’un ou plusieurs objets ont été supprimés de la relation.

"pre_clear"

Envoyé avant que la relation soit effacée.

"post_clear"

Envoyé après que la relation a été effacée.

reverse

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

model

La classe des objets qui sont ajoutés, supprimés ou retirés de la relation.

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

L’alias de base de données utilisé.

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 :

Et si nous faisions ensuite quelque chose comme ceci :

>>> t.pizza_set.remove(p)

les paramètres envoyés à un gestionnaire m2m_changed seraient :

class_preparedLien vers cette rubrique#

django.db.models.signals.class_preparedLien vers cette définition#

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

La classe de modèle qui vient d’être préparée.

pre_migrateLien vers cette rubrique#

django.db.models.signals.pre_migrateLien vers cette définition#

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

Une instance AppConfig de l’application sur le point d’être migrée/synchronisée.

app_config

Identique à 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.

stdout

Un objet de type flux vers lequel sera redirigée la sortie verbeuse.

using

L’alias de base de données sur laquelle une commande va agir.

plan

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

apps

Une 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#

django.db.models.signals.post_migrateLien vers cette définition#

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

Une instance AppConfig de l’application qui vient d’être installée.

app_config

Identique à 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.

stdout

Un objet de type flux vers lequel sera redirigée la sortie verbeuse.

using

L’alias de base de données utilisé pour la synchronisation. La valeur par défaut correspond à la base de données default.

plan

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

apps

Une 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
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_startedLien vers cette rubrique#

django.core.signals.request_startedLien vers cette définition#

Envoyé lorsque Django commence à traiter une requête HTTP.

Paramètres envoyés avec ce signal :

sender

La classe de gestion – par ex. django.core.handlers.wsgi.WsgiHandler – qui est chargée de la requête.

environ

Le dictionnaire environ fourni à la requête.

request_finishedLien vers cette rubrique#

django.core.signals.request_finishedLien vers cette définition#

Envoyé lorsque Django a terminé l’envoi d’une réponse HTTP à un client.

Paramètres envoyés avec ce signal :

sender

La classe de gestion, comme ci-dessus.

got_request_exceptionLien vers cette rubrique#

django.core.signals.got_request_exceptionLien vers cette définition#

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

Inutilisé (toujours None).

request

L’objet HttpRequest.

setting_changedLien vers cette rubrique#

django.test.signals.setting_changedLien vers cette définition#

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

Le gestionnaire des réglages.

setting

Le nom du réglage.

valeur

La 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.

enter

Une valeur booléenne ; True si le réglage doit être appliqué, False s’il doit être restauré.

template_renderedLien vers cette rubrique#

django.test.signals.template_renderedLien vers cette définition#

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.

Paramètres envoyés avec ce signal :

sender

L’objet Template qui a été produit.

template

Identique à sender

context

L’objet Context avec lequel le gabarit a été produit.

connection_createdLien vers cette rubrique#

django.db.backends.signals.connection_createdLien vers cette définition#

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

La classe d’adaptation de la base de données – c’est-à-dire django.db.backends.postgresql.DatabaseWrapper ou django.db.backends.mysql.DatabaseWrapper, etc.

connection

La 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.