Django: Как защитить от одновременной модификации записей базы данных

Question

Если есть способ защитить от одновременной модификации одной и той же записи базы данных двумя или более пользователями?

Было бы приемлемым показать сообщение об ошибке пользователю, выполняющему вторую операцию фиксации/сохранения, но данные не должны быть перезаписаны без изменений.

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

Answer 1

Для обеспечения безопасности база данных должна поддерживать transactions.

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

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

Я не знаю, Джанго, так что я не могу дать вам Teh cod3s ..;)

Answer 2

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

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

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

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

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

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

UPDATE ... WHERE version = 'version_from_user'; 

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

Answer 3

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

Answer 4

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

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

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

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

Answer 5

Отсюда:
How to prevent overwriting an object someone else has modified

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

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() 

Answer 6

Это, как я оптимистическая блокировка в 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.

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

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

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

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

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

Answer 7

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

Answer 8

Идея выше

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() 

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

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

Я рассмотрел идею пользовательского менеджера.

Я планирую переопределить метод 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 реализует довольно некоторое voodoo в этой области через django.db.models.deletion.Collector.

Странно, что у инструмента modren, такого как Django, отсутствует руководство для контроля устойчивости.

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

Answer 9

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

select_for_update(nowait=True) 

см docs

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

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

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

Answer 10

Django 1.11 имеет three convenient options справиться с этой ситуацией в зависимости от бизнес-логики требований:

• 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 позволяет мне спокойно пропустить дублированные спусковой ,