On Oct 12, 4:47 pm, Steven Cummings <estebis...@gmail.com> wrote: > If you're ensuring a set of data from some other source, what's the use of > knowing what was new? Are there other concrete cases where this might be > useful?
The standard use when synchronizing data is to make sure there aren't too many changes. This is to protect for corrupted data. For example if more than 10% of the data changed, then rollback the action. Send an email to administrator who needs to validate the changes by had. Granted, without models.UNCHANGED this use case has limited value. Another use case is overriding model.save(), and based on the action you might want to create an entry in another table. Something like when saving User, if the user was created, then save a Profile for him. Or just displaying "The object was successfully created"/"The object was successfully updated" to the user. This would be more useful even in manage.py shell: >>> someobj.save() INSERTED >>> someobj.save() UPDATED vs. >>> someobj.save() 1 >>> someobj.save() 1 Then there is the possibility that some day we could support the UNCHANGED return value. This would be actually cheap to do if Django would support update of only changed fields. We couldn't support that return value if the only choices would be just 1/0 return values. One way to see that there might be some uses for this, is that post_save does have a created argument. And then there is the question that what does this cost Django? The only cost I can see is that you can't do save_count += obj.save() but you need to do save_count += obj.save() and 1 or 0. > > I agree that model.save() should never return 0/None/models.NOACTION, > > that should be an exception instead of a return value. After .save() > > the model should exists in the database. If the object for some reason > > isn't persisted, it is worth an exception instead of easy to miss > > return value. > > Possibly, but an exception cannot be added until the programmer is passing a > precondition and can reasonable expect the condition of nothing being saved. > That's definitely not on this ticket. Agreed. The only question is: If we don't want to support the models.UPDATED / models.INSERTED return values, and we decide that 0 should not be ever returned, then why return the 1? That will be a return value of no information. If you are not going to do the models.UPDATED/INSERTED return value, then using up the .save() return value should not be done at this time. We can't change the return value at will, so we should not commit to something which doesn't have any use now, and might not have any use ever. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
