On Wed, Oct 12, 2011 at 9:35 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi>wrote:
> On Oct 12, 4:47 pm, Steven Cummings <estebis...@gmail.com> wrote: > 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. > Fair enough. That is an interesting possibility. > > 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. > Well, obviously I hope it does have use in the original ticket that spawned this one. I guess what I might need some help with here is: what are some of the directions of the ORM that might affect this decision. The reasons I stuck with counts across the board in this change were: 1. A uniform interface: object counts all the time for create/updated/delete. 2. Ready support for cascading updates if Model.save() were to ever trigger save() on related models that were dirty. Admittedly #2 is speculative, but so are the examples above of supporting update of only fields that have changed. So, is there a good sense of "sure" or "probable" enhancements to models that could help us with the return API of Model.save, and whether QuerySet.delete should return counts that include related objects? If "coming enhancements" or directions for Models can concretely inform, that would be great. Thoughts? -- Steven -- 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.
