On Oct 13, 5:40 am, Steven Cummings <estebis...@gmail.com> wrote: [About the 1/0 return value of .save()] > 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.
My point is that we should never just return 0 if there is a concurrent modification or some other reason for not being able to persist the object state. Why? When you request obj.save() you are requesting the object state to be persisted. If that can't be done, it's an exception. delete() does not have the same problem: if you do a delete, and the object is already deleted, then there is no problem. The DB state is still synchronized with the delete. The biggest problem of just returning 0 from the .save() on concurrent modification is that if the developer forgets to do if obj.save(): ... else: "show error" and instead does only a obj.save(), the application thinks the data was saved when in fact it was not. In the best case you will get an angry call from the user. Users don't like it when an application claims the data was saved but in fact it was not. In the worst case, you are doing other saves in the same request, and the state is half-persisted. Which is a data corruption bug right there. If instead .save() throws an exception, and the developer forgets to try-catch it, the user gets a 500 page. This is better than claiming the data was saved when it wasn't, and much better than doing a half- save. Also, if you just return 0, you will lose the information WHY the object couldn't be saved, you just know it wasn't saved for some reason. Another way to think about this: when there is a unique constraint violation, we raise an exception (the one from the DB backend). To be consistent with returning 0 when the object can't be saved due to some other reason, shouldn't we just catch that exception and return 0? Bad idea, right? > 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. Agreed. Re point 1: An uniform interface would also be returning models.DELETED / models.ALREADY_DELETED(?) from .delete(). Granted, in the #1 case 0/1 makes more sense. I do see the problem with model.delete() returning a number, while model.save() returns a constant. > 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. I don't think there is. For that reason I would just postpone the model.save() return value decision. I feel pretty strongly that model.save() should never return 0 in the meaning of "didn't save your changes" (note that this is different from "there were no changes"). It is just too easy to miss that return value and have half-done updates because of that. - Anssi Kääriäinen -- 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.
