DISCUSSION: Test to show the issue with using model.save() without update_fields #322
Conversation
|
One approach I have seen in another place is to have an additional column on tables and incrementing that value on each modification of a row. Then that value can be sent along with the form as a hidden field and in the save step be verified that no other modification has been made since the form was rendered. We could add support in iommi to at least help with implementing something like that. |
|
That's a slightly different thing I think. You could imagine a situation where the version number updates so often that the user can never save if it uses that approaching, while at the same time the admin interface only touches columns that are never updated by that other process. This is coincidentally my situation right now :) |
|
A more hacky fix could be to somehow calculate a default approximation to |
|
Yea, I was thinking to add all |
|
This is handled by #325 |
For example, I have a Task model used for scheduling. This has some fields that should not be edited by the user, like
last_checkedthat is used for a heartbeat, or ashutdown_commandfield that is used during deploy to tell the old job to gracefully shut down. If I edit the other fields of this Task in the admin, those other fields are also written, potentially overwriting data at crucial times if I'm very unlucky.