Signaux Django et méthode de sauvegarde prioritaire

Question

J'ai du mal à comprendre ce que je pense. En ce moment, j'ai quelques modèles qui ressemblent un peu à ça:

 def Review(models.Model)
    ...fields...
    overall_score = models.FloatField(blank=True)

def Score(models.Model)
    review = models.ForeignKey(Review)
    question = models.TextField()
    grade = models.IntegerField()

Une revue contient plusieurs "notes", la note globale est la moyenne des notes. Lorsqu'un commentaire ou une note est enregistré, je dois recalculer la moyenne de Overall_score. En ce moment, j'utilise une méthode de sauvegarde remplacée. Y aurait-il des avantages à utiliser le répartiteur de signaux de Django?

Answer 1

Les signaux de sauvegarde / suppression sont généralement favorables dans les cas où vous devez apporter des modifications qui ne sont pas complètement spécifiques au modèle en question, ou qui peuvent être appliquées à des modèles ayant quelque chose en commun ou pouvant être configurés pour être utilisés entre modèles. .

Une des tâches courantes des méthodes save remplacées est la génération automatisée de slugs à partir d'un champ de texte d'un modèle. C’est un exemple de ce qui, si vous deviez l’implémenter pour un certain nombre de modèles, gagnerait à utiliser un signal pre_save , où le gestionnaire de signal pourrait prendre le nom du champ slug et le nom de le champ à partir duquel générer le slug. Une fois que vous avez installé quelque chose de ce genre, toute fonctionnalité améliorée que vous avez mise en place s’appliquera également à tous les modèles - par exemple En recherchant le slug que vous êtes sur le point d'ajouter pour le type de modèle en question, afin de garantir l'unicité.

Les applications réutilisables bénéficient souvent de l’utilisation de signaux. Si les fonctionnalités qu’elles fournissent peuvent être appliquées à n’importe quel modèle, elles ne voudront généralement pas (sauf si cela est inévitable) que les utilisateurs soient obligés de modifier directement leurs modèles pour en bénéficier. .

Avec django-mptt , par exemple, j'ai utilisé le pre_save signal pour gérer un ensemble de champs décrivant une arborescence pour le modèle sur le point d'être créé ou mis à jour et le signal pre_delete pour supprimer les détails de l'arborescence de l'objet à supprimer et ses sous-arbre entier des objets avant et ils sont supprimés. En raison de l'utilisation de signaux, les utilisateurs n'ont pas besoin d'ajouter ou de modifier les méthodes save ou delete sur leurs modèles pour que cette gestion soit effectuée, il leur suffit de laisser django-mptt sait quels modèles ils souhaitent gérer.

Answer 2

Vous avez demandé:

Y aurait-il des avantages à utiliser le répartiteur de signaux de Django?

J'ai trouvé cela dans la documentation Django:

  

Les méthodes de modèle annulées ne sont pas appelées lors d'opérations en bloc

     

Notez que la méthode delete () pour un objet n'est pas nécessairement appelée.   lors de la suppression d'objets en vrac à l'aide d'un QuerySet ou à la suite d'une   suppression en cascade. Pour vous assurer que la logique de suppression personnalisée est exécutée, vous   peut utiliser les signaux pre_delete et / ou post_delete.

     

Malheureusement, il n'existe pas de solution de contournement lors de la création ou de la mise à jour.   objets en vrac, puisqu’aucun de save (), pre_save et post_save ne sont   appelé.

De: Remplacement des méthodes de modèle prédéfinies

Answer 3

Si vous utilisez des signaux, vous pourrez mettre à jour le score de révision à chaque fois que le modèle de score associé est enregistré. Mais si vous n’avez pas besoin de cette fonctionnalité, je ne vois aucune raison de le mettre en évidence, c’est plutôt intéressant en termes de modèle.

Answer 4

C'est une sorte de dénormalisation. Regardez cette jolie solution . Définition du champ de composition sur place.

Answer 5

Petit ajout de docs Django sur la suppression en bloc (méthode .delete () sur les objets QuerySet ):

  

N'oubliez pas que cela sera, dans la mesure du possible, exécuté uniquement   SQL, et les méthodes delete () des instances d’objets individuels   pas nécessairement être appelé au cours du processus. Si vous avez fourni un   méthode delete () personnalisée sur une classe de modèle et vous voulez vous assurer qu'elle est   appelé, vous devrez supprimer «manuellement» les instances de ce modèle   (par exemple, en parcourant un QuerySet et en appelant delete () sur chaque   objet individuellement) plutôt que d'utiliser la méthode en bloc delete () d'un   QuerySet.

https://docs.djangoproject.com/ fr / 1.11 / topics / db / queries / # deleting-objects

Et mise à jour en masse (méthode .update () sur les objets QuerySet ):

  

Enfin, sachez que update () effectue une mise à jour au niveau SQL et,   ainsi, n’appelle aucune méthode save () sur vos modèles, ni   émettre les signaux pre_save ou post_save (qui sont une conséquence de   appelant Model.save ()). Si vous souhaitez mettre à jour plusieurs enregistrements pour une   modèle qui a une méthode save () personnalisée, boucle sur eux et appelez save ()

https://docs.djangoproject.com/en/ 2.1 / ref / models / querysets / # update

Answer 6

Les signaux sont utiles lorsque vous devez exécuter un processus à long terme et que vous ne voulez pas bloquer votre utilisateur en attente de sauvegarde.