Essentially, you want a compare-and--swap instruction for a database?
Have you considered using memcached atomicity (add and cas) to handle this
kind of thing? It might get pretty elaborate, but with just a cursory
thought seems doable.
-peter
On Sat, Aug 6, 2011 at 9:59 PM, Steven Cummings <estebis...@gmail.com>wrote:
> 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.
>
>
--
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.
