запросов
На каждый апдейт телеги делаю запрос к базе, затем если что то надо то меняю и сохраняю, дело в том, что может прийти второй апдейт где будут другие изменения и первый сохраняется, но второй, не взяв старые изменения, тоже сохраняется
Получатель что у первого изменения были попросту незамеченными
Храню первичным ключём айди пользователя и в jsonb формате объект пользователя со всей информацией
Что можете посоветовать? Пишу сюда как профи по этой бд
такого быть не может. Покажите запрос, которым обновляете
Как минимум — прочесть про mvcc и транзакцыи. Это сложная тема, попытка кодить по разрозненным рецэптам из чятика скорее всего приведёт к плохому результату.
Не вижу причин недоверять человеку. Напороть дажэ в транзакцыи очень несложно.
тогда мы стали свидетелями lost update по описанию. Конечно, так какой-то косяк именно в запросе/транзакции, но вопрос поставлен как есть
Взятие пользователя: SELECT data FROM users WHERE user_id = 123; Сохранение: UPDATE users SET data = '{}' WHERE user_id = 123; Где {} там объект пользователя, 123 это соответственно айди Опишу как я понимаю ситуацию >Пришел первый апдейт инфа1 = взятие пользователя с бд *изменения в инфа1* >Пришел второй апдейт инфа2 = взятие пользователя с бд *сохранение инфа1 в базу данных* *изменения в инфа2* *сохранение инфа2 в базу данных* Получилось так, что инфа1 сохранилась, но инфа2 имеет старые параметры без изменений в инфа1 и соответственно они были утеряны, как то так, надеюсь понятно описал https://t.me/pgsql/339656 ^ про это почитаю
добавьте колонку version и в update where условие обновлять только нужную версию
Мне в любом случае нужно что бы оба изменений сохранились В одном может быть изменения баланс а во втором снятие привилегии В итоге баланс не будет изменен хотя надо бы
если update изменил 0 строк — значит он пытался обновить старую версию и нужно перечитать значение из строки и смержить по какому-то принципу
я так понимаю надо что бы апдейт всегда проходил по актуальным данным?
https://postgrespro.ru/docs/postgrespro/13/explicit-locking ?
Почитал, да, возможно это то что мне надо, гляну получится ли реализовать, но если есть ещё советы то готов выслушать Так как возможных решений много, но мне нужно выбрать одно, так как они все сложные в плане реализации
Ага. Event Sourcing.
это классическая проблема web gui интерфейсов, когда поля формы редактирования в браузере у клиента содержат значения которые уже 100500 раз перезаписаны в базе другими апдейтами и когда клиент нажимает save — данные всех этих других апдейтов (сделанных в других вкладках например или другом браузере) — затираются, у плохо написанных приложений — затираются молча :-) обычно для решения этой проблемы вводят версию строки и save формы обновляет только если версия в базе совпадает с версией данных в форме, а если не совпадает то показывает ошибку или предложение смержить изменения. в исходном вопросе есть слово «бот» так что там скорее всего как раз «формы ввода обновляемые асинхронно из нескольких клиентов» и явные блокировки тут не помогут, не будете же вы держать сессию для каждого клиента бота с блокировкой. но вообще я не вчитывался, возможно там и проще ситуация и всё решит select for update :-)
я думаю select for update решит, но варианты да - разные могут быть
Ну по хорошему вам нужна очередь, в которую добавляются корректировки, а уже из очереди вносятся изменения в базу. Иначе может произойти нарушение последовательности изменений и результат в базе окажется некорректным
очередь не гарантирует четкую последовательность, вроде
Жэсть. Ненадо так делать в RDBMS. Тут есть встроенные средства изоляцыи и сериализацыи, делать что-то внешнее имеет смысл только когда они исчерпаны.
Обсуждают сегодня