ORM и изменения объекта в разных местах кода?

собственно, да, так и есть. проблема в том, что user.account и transaction.account — это разные питонячие объекты, хотя логически они предславляют один и тот же объект БД. поэтому вызывая по очереди user.account.save() и transaction.account.save(), вторая операция может сохранить данные, которые не учитывают изменения, сделанные в первой итерации

ORM и изменения объекта в разных местах кода?

на самом деле в проекте обновление происходит в одной транзации. т.е. сначала мы где-то вытаскиваем из БД объект в две разные переменные: user.account, transaction.account. это происходит в разных частях системы. потом так получается, что эти два объекта попадают в одну функцию, примерно так:

def recalculate(user, transaction, some_amount, another_amount):
____revert(user, some_amount)
____income(transaction, another_amount)

прошу прощения, редактор съедает пробелы в начале строки в комментариях

в revert происходит первое обновление счета, через user.account, а в income — второе, через transaction.account. вся функция recalculate обернута в одну транзакцию. но с точки зрения БД все это выглядит хорошо и наивно: просто выполняются два update запроса по-очереди. причем тут гарантированно нет никакой конкуренции, запросы точно выполняются один за другим. но вот значение, которое ставит второй update запрос неверное, вот и получается проблема

ORM и изменения объекта в разных местах кода?

ну и собственно первая транзакция может быть успешно завершена, а вторая уже после перепишет значение. разве нет?

ORM и изменения объекта в разных местах кода?

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