2009-11-07 5 views

Répondre

6

Peut-être devrait, mais ce n'est pas le cas. .update() n'appelle pas la méthode .save() sur les objets individuels dans le QuerySet et met à jour à la place tout dans un seul appel SQL (UPDATE, comme il arrive). Comme il n'utilise pas .save(), il serait incohérent d'appeler les signaux pré et post-sauvegarde. Je peux certainement envisager des cas d'utilisation dans lesquels on pourrait vouloir le faire, mais je peux aussi envisager des cas dans lesquels on ne le ferait pas. Il me semble que ne pas appeler les signaux pré et post-sauvegarde est le comportement correct ici car il laisse plus de flexibilité pour le programmeur. Il n'est pas difficile de déclencher ces signaux manuellement, et je pense que c'est une meilleure décision de conception de demander aux programmeurs de se rappeler de déclencher les signaux pour obtenir le comportement désiré plutôt que de leur demander de se déconnecter des signaux pour éviter tout comportement indésirable.

+1

Bien que les raisons mentionnées, je pense que ce comportement est en quelque sorte incohérent, car la méthode queryset.delete() n'appelle pas delete() sur les instances simples, mais envoie les mêmes signaux que model.delete()! –

+1

De même, pour pouvoir envoyer des signaux liés à la sauvegarde sur un jeu de requête, ils doivent essentiellement sélectionner les éléments en plus de la mise à jour, ce qui élimine les avantages d'une méthode de mise à jour groupée. –