Hi Tim, Russell and Steven I agree it would be more useful to be able to work with locking from all places, not only the admin. The question then is how? :)
>From an implementation perspective, I also have a mild negative reaction to > the idea of using a separate table in the database for locks. Using a > database row to marshal this behavior sounds like adding load to a database > when all you need is a transient marker. A backend API that lets you use > memcache, redis, or even a file-based backend might be called for. And > that's assuming we take the "separate lock table" approach - I can think of > other approaches that involve version indicators on the model itself. I think having a separate lock table can and should be avoided with a general locking solution and that it's solvable without adding to the query count. For my use cases a version field on each table would fit nicely, and a transient datastore would not be safe enough, but more opinions are needed on this of course. I first tried to look into the "save with conditions" idea, but couldn't make it fit. I did not see a way to pass information about what happened (modification count/update count) from save_base, to save, to an overriding save method, without breaking existing apps heavily. That's also mentioned as a challenge in the ticket. Secondly, i tried an approach that adds an OptimisticLockingModel model that extends the _do_update() method. A very naive POC can be found at: https://github.com/runekaagaard/django-lock-the-admin/compare/optimistic-locking?expand=1#diff-c000f88621a9da867b462e1cf3e7cb36R13 That works for the admin in the sense that exceptions are thrown, and all the data is safe. I think the "matched vs. updated" issue goes away because a matched row is also always updated by the version field being incremented. Which drawbacks and edge cases can you see in such an solution? A whole other issue is how to handle the deletion of already deleted objects. Best, Rune Kaagaard -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/d7c659b8-bc81-4cb0-8011-26460e6d1f6a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
