Tuesday, November 25, 2014

Re: Preventing race conditions when submitting forms

On 2014-11-25 07:57, Paul Johnston wrote:
> Consider an e-commerce site, where Alice and Bob are both editing
> the product listings. Alice is improving descriptions, while Bob is
> updating prices. They start editing the Acme Wonder Widget at the
> same time. Bob finishes first and saves the product with the new
> price. Alice takes a bit longer to update the description, and when
> she finishes, she saves the product with her new description.
> Unfortunately, she also overwrites the price with the old price,
> which was not intended.

The common solution in this case your model would have something like
a "last_modified_timestamp" or "last_modified_counter". This would
be sent with the form and then resubmitted back. If the
timestamp/counter is the same, you know it's safe to update the
timestamp or increment the counter (done within the transaction to
ensure atomicity). If it's *not* the same timestamp/counter as it was
when the form was created, you know that it's been modified in the
interim and you can present a conflict-resolution form.

I don't think Django has anything like this out of the box, but it's
fairly straightforward to implement. I've done it enough times that
I should just create some model/form mixin to handle it for me.

-tkc



--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20141125130116.43f68a69%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment