Signaux Django vs méthode de sauvegarde prioritaire

Question

Je n'arrive pas à résoudre ce problème. En ce moment j'ai quelques modèles qui ressemble un peu comme ceci:

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() 

Un examen est a plusieurs « scores », la overall_score est la moyenne des scores. Lorsqu'un avis ou un score est enregistré, je dois recalculer la moyenne globale_score. En ce moment j'utilise une méthode de sauvegarde surchargé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 situations où vous devez apporter des modifications qui ne sont pas complètement spécifiques au modèle en question ou qui pourraient être appliquées à des modèles qui ont quelque chose en commun ou peuvent être configurés des modèles.

Une tâche courante dans les méthodes save remplacées est la génération automatique de slugs à partir d'un champ de texte dans un modèle. C'est un exemple de quelque chose qui, si vous deviez l'implémenter pour un certain nombre de modèles, aurait avantage à utiliser un signal pre_save, où le gestionnaire de signal pourrait prendre le nom du champ slug et le nom du champ pour générer le slug de . Une fois que vous avez quelque chose comme cela en place, toute fonctionnalité améliorée que vous mettez en place s'appliquera également à tous les modèles - par ex. en regardant la limace que vous êtes sur le point d'ajouter pour le type de modèle en question, pour assurer l'unicité.

Les applications réutilisables bénéficient souvent de l'utilisation de signaux - si la fonctionnalité qu'elles fournissent peut être appliquée à n'importe quel modèle, elles ne veulent généralement pas (sauf si c'est inévitable) que les utilisateurs modifient directement leurs modèles pour bénéficier de il.

Avec django-mptt, par exemple, j'utilise le signal pre_save pour gérer un ensemble de champs qui décrivent une structure arborescente pour le modèle qui est sur le point d'être créé ou mis à jour et le signal pre_delete pour éliminer les détails de la structure de l'arbre pour l'objet supprimé et son sous-arbre entier d'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 faite pour eux, ils doivent simplement indiquer à django-mptt quels modèles ils veulent gérer.

Answer 2

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 je n'ai pas besoin d'une telle fonctionnalité, je ne vois aucune raison de mettre cela en évidence, c'est plutôt joli.

Answer 3

C'est une sorte de dénormalisation. Regardez ce pretty solution. Définition du champ de composition en place.

Answer 4

Les signaux sont utiles lorsque vous devez exécuter un processus à long terme et que vous ne voulez pas empêcher votre utilisateur d'attendre la fin de la sauvegarde.

Answer 5

Vous avez demandé:

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

Je trouve cela dans les django docs:

méthodes de modèle OPPOSER ne sont pas appelés sur les opérations en vrac

Notez que la méthode de suppression() pour un objet est pas nécessairement appelé lors de la suppression d'objets en bloc à 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 pouvez utiliser les signaux pre_delete et/ou post_delete.

Malheureusement, il n'y a pas une solution de contournement lors de la création ou la mise à jour objets en vrac, car aucun de sauvegarde(), pre_save et post_save sont appelés .

De: Overriding predefined model methods