Interesting feature I hadn't noticed in memcached. That does seem like it
would do the trick where memcached is being used. I think the ability to
control it in Django would generally still be desirable though, as that is
where the data ultimately lives and I'd be hesitant to assume to control the
DB's concurrency from memcached. Ideally it should be the other way around.
--
Steven
On Sun, Aug 7, 2011 at 8:00 PM, Peter Portante
<peter.a.porta...@gmail.com>wrote:
> 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.
>
--
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.
