On Wed, Oct 12, 2011 at 11:51 PM, Anssi Kääriäinen
<anssi.kaariai...@thl.fi>wrote:
>
>
> 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.
>
I'm not sure anybody said 0 would be returned for an *inability* to save
data. I would agree that would be an exception situation, but it hasn't been
discussed here yet.
>
> The biggest problem of just returning 0 from the .save() on concurrent
> modification is that if the developer forgets to do if obj.save(): ...
>
>
So the situation I expect this to occur in is the context of very deliberate
coding by the programmer, e.g.:
count = obj.save(where={'version': 1})
If the programmer forgets to check the count then they probably didn't
understand the feature being used to being with. I don't think this is going
to result in the accidents you're describing, because until there is a
specific feature context, save will return 1 (or whatever else we decide).
I've no intention of introducing implicit features or pitfalls.
>
> 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?
>
I generally agree with this, but as I stated above I've yet to discuss a
situation involving the inability to save. In the example so far the reason
for not saving is the condition given by the programmer. I won't be
swallowing any exceptions and returning zero, and if a coder chooses to
avoid saving on a version for optimistic concurrency, that is a decision,
not an inability.
> > 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.
>
I think a reasonable option to discuss might be leaving the save() API as it
is and rolling this enhancement back to the internal code (i.e.,
UpdateQuery, DeleteQuery) returning counts to support the prospective
enhancements I've alluded to, and/or overrides of save(). Until there are
any changes to save(), I agree it is not going to be useful info. However
for delete it seems immediately usable (and then we're left with the debate
of counting immediate-only or including related objects).
--
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.
