Bad community member that I am, I jumped the gun and logged a ticket
[1] on this one... anyway:
Websites general avoid overly aggressive locking of data to deal with
concurrency issues. When two users allowed to edit some data are
simultaneously doing so, they're both allowed to do so and the
last .save() wins (race condition). This is largely acceptable on the
web as when two people are allowed to edit data they shouldn't be
prevented to doing so. Further sites often have audit history (whether
or not exposed to those users owning/managing the data) which tracks
exactly what went on.
However, some sites may wish to detect this situation and present the
2nd user with a page or the previous form stating that what they
edited is now obsolete. Examples of situations where we don't want
edits to be silently stomped are health and financial data. Bugzilla
mid-air collisions are an example of an implementation in the wild.
So, we could try to detect this by always re-querying the object just
before update (or delete), but with sufficient traffic there is still
the chance that two requests *think* they know the current state of it
in storage. This is where knowing rows modified, and/or having a
precondition check would help. I've outlined the details on the
ticket, but generally:
* To ensure the object I'm saving is not stale, I might like to do
Model.save_if(version=version), where I have an incremented version-
field and save_if would compare the stored value (using something like
an F('version')) against the given value. If the version was
different, it should raise something like PreconditionFailed.
* For delete()s, it might be nice to get rows-modified to know that
the current request really did perform the delete. This is important
in cases like using an OAuth auth code, where allowing multiple uses
(deletes) of it would be a security problem.
For both these cases, it would also be useful to either get rows-
modified (or precondition-met) in the post-save/delete signal, or to
somehow avoid those signals firing when no data was updated.
I'm fully willing to hack on this and provide patches and/or use an
experimental branch, just wanted to get some thoughts on it.
[1] https://code.djangoproject.com/ticket/16549
--
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.
