Предпочтительный параллелизм базы данных/веб-приложения разрабатывает, когда многочисленные пользователи могут отредактировать те же данные
Убедитесь, что Sublime использует версию Python 3.7, в которую вы установили библиотеки.
У этого парня были схожие проблемы: Ни один модуль с именем openpyxl - Python 3.6 - OSX
И решил с помощью этого вопроса: Как установить, какая версия Python использует возвышенный текст
4 ответа
Optimistic locking.
Pessimistic is harder to implement and will give problems in a web environment. What action will release the lock, closing the browser? Leaving the session to time out? What about if they then do save their changes?
You don't specify which database you are using. MS SQL server has a timestamp datatype. It has nothing to do with time though. It is mearly a number that will get changed each time the row gets updated. You don't have to do anything to make sure it gets changed, you just need to check it. You can achive similar by using a date/time last modified as @KM suggests. But this means you have to remember to change it each time you update the row. If you use datetime you need to use a data type with sufficient precision to ensure that you can't end up with the value not changing when it should. For example, some one saves a row, then someone reads it, then another save happens but leaves the modified date/time unchanged. I would use timestamp unless there was a requirement to track last modified date on records.
To check it you can do as @KM suggests and include it in the update statement where clause. Or you can begin a transaction, check the timestamp, if all is well do the update, then commit the transaction, if not then return a failure code or error.
Holding transactions open (as suggested by @le dorfier) is similar to pessimistic locking, but the amount of data locked may be more than a row. Most RDBM's lock at the page level by default. You will also run into the same issues as with pessimistic locking.
You mention in your question that you are worried about conflicting updates. That is what the locking will prevent surely. Both optimistic or pessimistic will, when properly implemented prevent exactly that.
вот простое решение для многих людей, работающих с одними и теми же записями.
когда вы загружаете данные, получаете дату последнего изменения, мы используем LastChgDate в наших таблицах
, когда вы сохраняете (обновить) данные добавить «AND LastChgDate = ранееLoadedLastChgDate» в предложение where. Если количество строк = 0 при обновлении, выдается ошибка, когда «кто-то уже сохранил эти данные», и выполняется откат всего, в противном случае данные сохраняются.
Обычно я использую вышеуказанную логику только для таблиц заголовков, а не для деталей таблицы, поскольку все они находятся в одной транзакции.
Я согласен с первым ответом выше, мы пытаемся использовать оптимистическую блокировку, когда вероятность коллизий довольно низка. Это можно легко реализовать с помощью столбца LastModifiedDate или увеличения столбца версии. Если вы не уверены в частоте столкновений, запишите их где-нибудь, чтобы вы могли следить за ними. Если ваши записи всегда находятся в режиме «редактирования», имея отдельные «просмотр» и «редактирование» режимы могут помочь уменьшить коллизии (при условии, что вы перезагружаете данные при входе в режим редактирования).
Если коллизии все еще высоки, пессимистическую блокировку сложнее реализовать в веб-приложениях, но определенно возможно. У нас был хороший успех с «арендованными» записями (блокировка с таймаутом) ... похоже на то двухминутное предупреждение, которое вы получаете, когда покупаете билеты на TicketMaster. Когда пользователь переходит в режим редактирования, мы помещаем запись в таблицу «блокировки» с таймаутом N минут. Другие пользователи увидят сообщение, если попытаются отредактировать запись с активной блокировкой. Вы также можете реализовать сохранение активности для длинных форм, продлив аренду при любой обратной передаче страницы или даже с помощью таймера ajax. Также нет причин, по которым вы не могли бы поддержать это стандартной оптимистической блокировкой, упомянутой выше.
Я предполагаю, что вы столкнулись с проблемой «потерянного обновления».
Чтобы противостоять этому, как правило, я использую пессимистичный блокировка, когда вероятность столкновения высока (или транзакции недолговечны), и оптимистическая блокировка, когда вероятность столкновения низка (или транзакции долгоживущие, или ваши бизнес-правила охватывают несколько транзакций).
Вам действительно необходимо посмотрите, что применимо к вашей ситуации, и сделайте свой приговор.