Concurrency in django admin change view

Question

My model:

class Order(models.Model):
    property_a = models.CharField()
    property_b = models.CharField()
    property_c = models.CharField()

Many users will access a given record in a short time frame via admin change page, so I am having concurrency issues:

User 1 and 2 open the change page at the same time. Assume all values are blank when they load the page. User 1 sets property_a to "a", and property_b to "b", then saves. A second later if user 2 changes property b and c then saves, it will quietly overwrite all the values from user 1. in this case, property_a will go back to being blank and b and c will be whatever user 2 put in.

I need recommendations on how to handle this. If I have to have a version field in the model, how do i pass it to the admin, where do I do the check so I can elegantly notify the user their changes can't be saved because another user has modified the record? Is there a more seamless way than just returning an error to the user?

Answer 1

The standard solution is to prevent your users from sharing a single record. It's not at all clear why so many users are messing with the exact same Order instance.

Consider that Order is probably a composite object and you've put too much into a single model. That's the first -- and best -- solution.

If (for inexplicable reasons) you won't decompose this, then you have to create a two-part update transaction.

1. Requery the data. Compare with the original query as done for this user's session.

2. If the data doesn't match the original query, then someone else changed it. The user's changes are invalidated, rolled back, wiped out, and the user sees a new query.

3. If the data does match, you can try to commit the change.

The above algorithm has a race condition, which is usually resolved via low-level SQL. Note that it invalidates a user's work, making it maximally irritating.

That's why your first choice is to decompose your models to eliminate the concurrency.

---

my model has a miscellaneous notes field

This is a bad design. (a) Concurrency is ruined by collisions on this field. (b) There's no log or history of comments.

Item (b) means that a badly-behaved user can maliciously corrupt this data. If you keep notes and comments as a log, you can -- in principle -- limit users to changing only their own comments.

[In most databases with "miscellaneous notes" the field has become a costly, hard-to-maintain liability full of important but impossible-to-parse data. Miscellaneous notes is where users invent their own processes outside the application software. ]

"miscellaneous notes" must be treated like a log, with an unlimited number of notes -- date-stamped -- identified by user -- appended to the Order.

If you simply partition the design to put notes in a separate table, you solve your concurrency issues.