Django: как я могу защитить себя от одновременного изменения записей базы данных

Вот как я использую оптимистическую блокировку в Django:

updated = Entry.objects.filter(Q(id=e.id) && Q(version=e.version))\
          .update(updated_field=new_value, version=e.version+1)
if not updated:
    raise ConcurrentModificationException()

Перечисленный выше код может быть реализован как метод в Custom Manager.

Я делаю следующие предположения:

• filter (). update () приведет к единственному запросу к базе данных, потому что фильтр ленив
• запрос к базе данных является атомарным

Этих предположений достаточно, чтобы гарантировать, что никто другой не обновлял запись раньше. Если таким образом обновляются несколько строк, следует использовать транзакции.

ПРЕДУПРЕЖДЕНИЕ Django Doc:

Имейте в виду, что метод update () преобразуется непосредственно в оператор SQL. Это массовая операция для прямых обновлений. Он не запускает никаких методов save () на ваших моделях и не испускает сигналы pre_save или post_save.

Этот вопрос немного устарел, и мой ответ немного запоздал, но после того, что я понимаю, это было исправлено в Django 1.4 с помощью:

select_for_update(nowait=True)

см. документы

Возвращает набор запросов, который блокирует строки до конца транзакции, генерируя SQL-оператор SELECT ... FOR UPDATE для поддерживаемых баз данных.

Обычно, если другая транзакция уже установила блокировку одной из выбранных строк, запрос будет блокироваться до тех пор, пока блокировка не будет снята. Если это не то поведение, которое вам нужно, вызовите select_for_update (nowait = True). Это сделает звонок неблокирующим. Если конфликтующая блокировка уже получена другой транзакцией, при оценке набора запросов будет вызвана ошибка DatabaseError.

Конечно, это будет работать только в том случае, если серверная часть поддерживает функцию «выбрать для обновления», чего, например, нет в sqlite. К сожалению: nowait=True не поддерживается MySql, вы должны использовать: nowait=False, который будет блокироваться только до тех пор, пока блокировка не будет снята.

На самом деле, транзакции здесь не особо помогают ... если только вы не хотите, чтобы транзакции выполнялись по нескольким HTTP-запросам (что вам, скорее всего, не нужно).

В таких случаях мы обычно используем «Оптимистическую блокировку». Насколько мне известно, Django ORM этого не поддерживает. Но было некоторое обсуждение добавления этой функции.

Так что вы сами по себе. По сути, вам следует добавить в модель поле «версия» и передать его пользователю как скрытое поле. Обычный цикл обновления:

1. прочитать данные и показать их пользователю
2. пользователь изменяет данные
3. пользователь публикует данные
4. приложение сохраняет его обратно в базу данных.

Чтобы реализовать оптимистическую блокировку, при сохранении данных вы проверяете, совпадает ли версия, полученная вами от пользователя, с версией в базе данных, а затем обновляете базу данных и увеличиваете версию. Если это не так, это означает, что с момента загрузки данных произошли изменения.

Вы можете сделать это с помощью одного вызова SQL, например:

UPDATE ... WHERE version = 'version_from_user';

Этот вызов обновит базу данных только в том случае, если версия осталась прежней.

Django 1.11 имеет три удобных варианта для обработки эта ситуация зависит от требований вашей бизнес-логики:

• Something.objects.select_for_update() будет блокироваться, пока модель не станет свободной
• Something.objects.select_for_update(nowait=True) и поймать DatabaseError, если модель в настоящее время заблокирована для обновления
• Something.objects.select_for_update(skip_locked=True) не вернет объекты, которые в данный момент заблокированы

В моем приложении, которое имеет как интерактивные, так и пакетные рабочие процессы на различных моделях, я нашел эти три варианта для решения большинства моих сценариев параллельной обработки.

«Ожидание» select_for_update очень удобно в последовательных пакетных процессах - я хочу, чтобы они все выполнялись, но пусть они не торопятся. nowait используется, когда пользователь хочет изменить объект, который в настоящее время заблокирован для обновления - я просто скажу им, что он модифицируется в данный момент.

skip_locked полезен для другого типа обновления, когда пользователи могут запускать повторное сканирование объекта - и мне все равно, кто его запускает, пока он запускается, поэтому skip_locked позволяет мне молча пропускать повторяющиеся триггеры.

Для дальнейшего использования ознакомьтесь с https://github.com/RobCombs/django-locking. Он выполняет блокировку таким образом, чтобы не оставлять постоянных блокировок, путем сочетания разблокировки javascript, когда пользователь покидает страницу, и тайм-аутов блокировки (например, в случае сбоя браузера пользователя). Документация довольно полная.

Вам, вероятно, следует использовать по крайней мере промежуточное программное обеспечение транзакций django, даже независимо от этой проблемы.

Что касается вашей реальной проблемы, когда несколько пользователей редактируют одни и те же данные ... да, используйте блокировку. ИЛИ:

Проверьте, с какой версией обновляется пользователь (делайте это безопасно, чтобы пользователи не могли просто взломать систему, чтобы сказать, что они обновляют последнюю копию!), И обновляйте только в том случае, если эта версия актуальна. В противном случае отправьте пользователю новую страницу с исходной версией, которую он редактировал, представленной версией и новой версией (-ами), написанной другими. Попросите их объединить изменения в одну, полностью обновленную версию. Вы можете попытаться объединить их автоматически, используя набор инструментов, например diff + patch, но вам все равно понадобится ручной метод объединения, работающий в случаях сбоя, так что начните с этого. Кроме того, вам необходимо сохранить историю версий и разрешить администраторам отменять изменения на случай, если кто-то непреднамеренно или намеренно испортит слияние. Но вы, вероятно, все равно должны это иметь.

Скорее всего, есть приложение / библиотека django, которая делает большую часть этого за вас.

Еще одно слово, на которое стоит обратить внимание, - это слово «атомный». Атомарная операция означает, что изменение вашей базы данных либо произойдет успешно, либо явно не удастся. Быстрый поиск показывает этот вопрос об атомарных операциях в Django.

Идея выше

updated = Entry.objects.filter(Q(id=e.id) && Q(version=e.version))\
      .update(updated_field=new_value, version=e.version+1)
if not updated:
      raise ConcurrentModificationException()

отлично выглядит и должен нормально работать даже без сериализуемых транзакций.

Проблема в том, как улучшить поведение глухого .save (), чтобы не приходилось вручную подключаться к методу .update ().

Я посмотрел на идею Custom Manager.

Я планирую переопределить метод Manager _update, который вызывается Model.save_base () для выполнения обновления.

Это текущий код в Django 1.3.

def _update(self, values, **kwargs):
   return self.get_query_set()._update(values, **kwargs)

ИМХО нужно сделать что-то вроде:

def _update(self, values, **kwargs):
   #TODO Get version field value
   v = self.get_version_field_value(values[0])
   return self.get_query_set().filter(Q(version=v))._update(values, **kwargs)

Аналогичная вещь должна произойти при удалении. Однако удаление немного сложнее, поскольку Django внедряет в этой области довольно много вуду через django.db.models.deletion.Collector.

Странно, что у инструмента modren, такого как Django, нет руководства по Optimictic Concurency Control.

Я обновлю этот пост, когда отгадаю загадку. Надеюсь, решение будет приятным питоническим способом, не связанным с тоннами кодирования, странными представлениями, пропуском важных частей Django и т. Д.

В целях безопасности база данных должна поддерживать транзакции.

Если поля имеют "произвольную форму", например текст и т. д., и вам нужно разрешить нескольким пользователям редактировать одни и те же поля (вы не можете владеть данными одним пользователем), вы можете сохранить исходные данные в переменной. Когда пользователь выполняет фиксацию, проверьте, изменились ли входные данные по сравнению с исходными данными (если нет, вам не нужно беспокоить БД, перезаписывая старые данные), если исходные данные по сравнению с текущими данными в БД совпадают вы можете сохранить, если он изменился, вы можете показать пользователю разницу и спросить пользователя, что делать.

Если в полях есть числа, например баланс счета, количество товаров в магазине и т. д., вы можете обрабатывать его более автоматически, если вычислите разницу между исходным значением (сохраненным, когда пользователь начал заполнять форму) и новым значением, вы можете начать транзакцию, прочитав текущее значение и добавьте разницу, затем завершите транзакцию. Если у вас не может быть отрицательных значений, вы должны прервать транзакцию, если результат отрицательный, и сообщить об этом пользователю.

Я не знаю django, поэтому не могу дать вам cod3s ..;)

Отсюда:
Как предотвратить перезапись объекта кто-то изменил

Я предполагаю, что метка времени будет храниться как скрытое поле в форме, детали которой вы пытаетесь сохранить.

def save(self):
    if(self.id):
        foo = Foo.objects.get(pk=self.id)
        if(foo.timestamp > self.timestamp):
            raise Exception, "trying to save outdated Foo" 
    super(Foo, self).save()