On Tue, Aug 9, 2011 at 1:33 PM, akaariai <akaar...@cc.hut.fi> wrote: > On Aug 9, 1:17 am, Steven Cummings <estebis...@gmail.com> wrote: >> I don't think we're talking about new or specific fields as part of the base >> implementation here. Just enhanced behavior around updates to: >> >> 1) Provide more information about the actual rows modified >> 2) Check preconditions with the actual DB stored values; and >> 3) Avoid firing post-update/delete signals if nothing was changed >> >> From there you could implement fields as you see fit for your app, e.g., >> version=IntegerField() that you use in a precondition. > > That would be useful. Especially if that can be done without too much > code duplication. > > I had another idea for optimistic locking: why not use the pre_save > signal for this? There is a proof of concept how to do this in > https://github.com/akaariai/django_optimistic_lock > > The idea is basically that if you add a OptimisticLockField to your > model, the pre_save (and pre_delete) signal will check that there have > been no concurrent modifications. That's it. > > The code is really quickly written and downright ugly. It is a proof > of concept and nothing more. I have tested it quickly using PostgreSQL > and it seems to work for simple usage. However, it will probably eat > your data.
That adds additional SELECT statements, which then extends a lock window between the check statement and the changes. It works, but in doing so it changes an optimistic lock into a pessimistic lock. IMHO the right way to do this would be to add the OptimisticLockField check as an additional item on the WHERE clause of the UPDATE or DELETE. If that action returns 0 rows then we know that the lock check failed and we can handle that. This keeps the locking optimistic and doesn't add any additional SQL statements. e.g. UPDATE foo SET col = newvalue, optimistic_lock_field = optimistic_lock_field + 1 WHERE pkcol = p_key AND optimistic_lock_field = p_version DELETE FROM foo WHERE pkcol = p_key AND optimistic_lock_field = p_version -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- 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.
