Opened 15 years ago
Closed 15 years ago
#12149 closed (invalid)
pre_save is not called before the overridden save() method on a model
Reported by: | siddhi | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | 1.1 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
If I have a model where I override the save() method, then the pre_save signal is not sent before the save method is called.
Example:
class MyModel(models.Model): name = models.CharField(max_length=20) def save(self, force_insert=False, force_update=False): if self.name == "dont_save": return super(Project, self).save(force_insert, force_delete)
def presave_handler(sender, instance, **kwargs): instance.name = "dont_save" signals.pre_save.connect(presave_handler, sender=MyModel, dispatch_uid="abc")
In the above case, the flow goes like this
- call overridden save method
- check the condition in save method (condition is false)
- call super
- call pre_save
- set name to "dont_save"
- object saved to database with name = "dont_save"
This is rather unintuitive that the pre_save gets called in the middle of the save method. Also, any processing done in the pre_save cannot be handled in the save method as the flow has gone to the super class by then.
The expected flow should be like this
- call overridden save method
- call pre_save
- set name to "dont_save"
- execution enters save method
- check condition in overridden save method (condition is true)
- return without saving
Change History (3)
follow-up: 2 comment:1 by , 15 years ago
Description: | modified (diff) |
---|---|
Resolution: | → invalid |
Status: | new → closed |
comment:2 by , 15 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Replying to kmtracey:
It isn't clear to me how you expect a signal to get sent at step 2 here:
- call overridden save method
- call pre_save
- set name to "dont_save".
At that point execution is in your own code, how is Django supposed to cause a signal to be sent?
As currently implemented, the signal can't be sent. But it should. That is the bug :) Perhaps steps 1 and 2 should be exchanged in that flow.
The design for sending the signals needs to be changed. Maybe the metaclass should automatically decorate the save method to send the signal before and after, instead of sending it within the parent save(). The right design and alternatives can be discussed.
As it stands, you cant use the changes from the pre_save within the custom save method. By the time pre_save is called execution is already out of the custom save and in the superclass. This is very illogical. You would expect a signal called pre_save would be triggered before the save.
comment:3 by , 15 years ago
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
The pattern you want is simply not possible with code, you need to manually send the signal (or some custom signal).
(Fixed formatting. Note you've got to put a space before the
1.
in your lists to get them to format properly.)The signals doc: http://docs.djangoproject.com/en/dev/ref/signals/#module-django.db.models.signals
notes that if you override
save()
you must call the parent class method in order for the signals to be sent. That makes it pretty clear the parent class code is what is going to send the signals. It isn't clear to me how you expect a signal to get sent at step 2 here:At that point execution is in your own code, how is Django supposed to cause a signal to be sent?