12

Django is sending the pre/post_delete signals if you are using the queryset.delete() method, but shouldn't it then also send pre/post_save on queryset.update()?

Dominic Rodger
  • 97,747
  • 36
  • 197
  • 212
Bernhard Vallant
  • 49,468
  • 20
  • 120
  • 148

2 Answers2

11

Perhaps it should, but it doesn't. .update() does not call the .save() method on the individual objects in the QuerySet, and instead updates the all in a single SQL call (UPDATE, as it happens). Since it doesn't use .save(), it would be inconsistent for it to call the pre- and post-save signals. I can certainly envision use-cases in which one might want it to do so, but I can also envision cases in which one wouldn't. It seems to me that not calling the pre- and post-save signals is the correct behavior here as it leaves more flexibility for the programmer. It's not hard to trigger those signals manually, and I think it's definitely a better design decision to ask programmers to remember to trigger the signals to get desired behavior than asking them to remember to disconnect the signals to avoid undesired behavior.

Matt
  • 5,028
  • 2
  • 28
  • 55
Josh Ourisman
  • 1,078
  • 1
  • 9
  • 16
  • 2
    Well though the reasons mentioned I think this is somehow inconsistent behaviour, because the queryset.delete() method also doesnt call delete() on the single instances, but it send the same signals as model.delete() does! – Bernhard Vallant Nov 07 '09 at 17:37
  • 1
    Also, in order to be able to send a save-related signals on a queryset, they'd essentially need to do a select for the elements in addition to the update, eliminating the benefits of having a bulk update method. – B Robster Nov 21 '12 at 16:10
0

I agree, .update() can be used to prevent a signal dispatch, for example if you wanna update an instance without firing a signal you should use it and not the .save() method.

Karim Bourahla
  • 37
  • 5