Django: Як я можу захистити від одночасної модифікації записів бази даних

Question 1

Якщо існує спосіб захисту від одночасних модифікацій однієї і тієї ж бази даних двома або більше користувачами?

Було б прийнятно показувати повідомлення про помилку користувачеві, який виконує другу операцію фіксації / збереження, але дані не повинні перезаписуватися мовчки.

Я думаю, що блокування входу не є можливим, оскільки користувач може скористатися кнопкою "Назад" або просто закрити браузер, залишивши блокування назавжди.

Question 2

Ось як я роблю оптимістичне блокування в 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

Question 3

Це питання трохи застаріле, і моя відповідь трохи пізня, але після того, що я розумію, це було виправлено в Django 1.4 за допомогою:

select_for_update(nowait=True)

див. документи

Повертає набір запитів, який заблокує рядки до кінця транзакції, генеруючи оператор SELECT ... FOR UPDATE SQL у підтримуваних базах даних.

Зазвичай, якщо інша транзакція вже отримала блокування в одному з вибраних рядків, запит буде блокуватися, доки блокування не буде звільнено. Якщо це не та поведінка, яку ви хочете, зателефонуйте select_for_update (nowait = True). Це зробить дзвінок неблокуючим. Якщо конфліктна блокування вже отримана іншою транзакцією, під час оцінки набору запитів буде викликано помилку DatabaseError.

Звичайно, це буде працювати лише в тому випадку, якщо внутрішній сервер підтримує функцію "вибрати для оновлення", яка, наприклад, sqlite не підтримує. На жаль: nowait=TrueMySql не підтримує, тут вам потрібно використовувати:, nowait=Falseякий буде блокувати лише доти, доки блокування не буде звільнено.

Question 4

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

У цих випадках ми зазвичай використовуємо "Оптимістичне блокування". Наскільки мені відомо, Django ORM цього не підтримує. Але були деякі обговорення щодо додавання цієї функції.

Отже, ви самі по собі. В основному, що ви повинні зробити, це додати поле "версія" до вашої моделі та передати його користувачеві як приховане поле. Звичайним циклом оновлення є:

прочитати дані та показати їх користувачеві
користувач змінює дані
користувач розміщує дані
додаток зберігає його назад у базі даних.

Для реалізації оптимістичного блокування, зберігаючи дані, ви перевіряєте, чи версія, яку ви отримали від користувача, така сама, як і версія бази даних, а потім оновлюєте базу даних та збільшуєте версію. Якщо вони не є, це означає, що відбулися зміни після завантаження даних.

Ви можете зробити це за допомогою одного виклику SQL, наприклад:

UPDATE ... WHERE version = 'version_from_user';

Цей дзвінок оновить базу даних лише у тому випадку, якщо версія буде незмінною.

Question 5

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дозволяє мені мовчки пропускати дубльовані тригери.

Question 6

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

Question 7

Ймовірно, вам слід скористатися проміжним програмним забезпеченням для транзакцій django, навіть незалежно від цієї проблеми.

Що стосується вашої фактичної проблеми, коли кілька користувачів редагують однакові дані ... так, використовуйте блокування. АБО:

Перевірте, до якої версії користувач оновлює (зробіть це надійно, щоб користувачі не могли просто зламати систему, сказавши, що оновлюють останню копію!), І оновлювати лише, якщо ця версія актуальна. В іншому випадку поверніть користувачеві нову сторінку з оригінальною версією, яку вони редагували, надісланою версією та новою версією, написаною іншими. Попросіть їх об’єднати зміни в одну, повністю сучасну версію. Ви можете спробувати автоматично об’єднати їх, використовуючи набір інструментів, як diff + patch, але вам все одно потрібно мати метод ручного злиття, який все одно працює для випадків відмов, тому починайте з цього. Крім того, вам потрібно буде зберегти історію версій і дозволити адміністраторам скасувати зміни, якщо хтось ненавмисно або навмисно переплутає об’єднання. Але у вас, мабуть, це все одно має бути.

Існує велика ймовірність програми / бібліотеки django, яка робить більшу частину цього за вас.

Question 8

Інше, на що слід звернути увагу, це слово «атомний». Атомна операція означає, що зміна бази даних відбудеться або успішно, або очевидно не вдасться. Швидкий пошук показує це запитання про атомні операції в Django.

Question 9

Ідея вище

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.

Мій план полягає в тому, щоб замінити метод _update Manager, який викликається Model.save_base () для виконання оновлення.

Це поточний код у Django 1.3

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

Що потрібно зробити IMHO, це щось на зразок:

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.

Дивно, що модрен-інструменту, як Django, не вистачає вказівок щодо оптимічного контролю надійності.

Я оновлю цю публікацію, коли розгадаю загадку. Будемо сподіватися, що рішення буде мати приємний пітонічний спосіб, який не передбачає тонн кодування, дивних поглядів, пропуску важливих частин Django тощо.

Question 10

Для безпеки база даних повинна підтримувати транзакції .

Якщо поля "вільної форми", наприклад, текст тощо, і вам потрібно дозволити декільком користувачам мати можливість редагувати однакові поля (ви не можете мати права власності на дані одного користувача), ви можете зберігати вихідні дані в змінна. Коли користувач фіксує, перевірте, чи змінилися вхідні дані від вихідних даних (якщо ні, то не потрібно турбувати БД переписуванням старих даних), якщо вихідні дані порівняно з поточними даними в базі однакові Ви можете зберегти, якщо воно змінилося, Ви можете показати користувачеві різницю та запитати у користувача, що робити.

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

Я не знаю django, тому я не можу дати вам cod3s ..;)

Question 11

Звідси:
Як запобігти перезапису об’єкта, який хтось інший змінив

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

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