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

Question

[stepank]

Допустим, есть некоторая система с БД. В этой системе есть три сущности:

— пользователь (User),

— транзакция (Transaction),

— счет пользователя (Account).



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



Работать с этим всем делом мы хотим через какой-нибудь ORM. В моем случае — это Django ORM.



Далее, пусть у нас есть некоторый счет, на котором изначально баланс равен 100. Также у нас есть транзакция (transaction) и пользователь (user), которые ссылаются на этот счет.



Теперь делаем следующее:



1. Обращаемся к полю user.account, чтобы объект счета вытянулся из БД в одну переменную:



print user.account



2. Обращаемся к полю transaction.account, чтобы объект счета вытянулся из БД в другую переменную:



print transaction.account



3. Обновляем счет у пользователя и сохраняем:

user.account.balance = 0<br/>
user.account.save()

4. Обновляем счет у транзакции (но уже по-другому) и тоже сохраняем:

transaction.account.balance += 100<br/>
transaction.account.save()

В итоге в БД хранится информация о том, что баланс равен 200, т.к. в пункте 4 ничего не известно о том, что произошло в пункте 3. И, хотя такой результат вполне логичен, он может быть весьма неожиданным.



Собственно, ситуация вполне реальная: пункты 1 и 2 могут находиться в разных частях системы и ничего друг о друге не знают.



В связи с чем есть пара вопросов:

1. Как избежать подобных ошибок, кроме как быть очень аккуратным?

2. Может быть, это проблема чисто Django ORM, как дела с Java Hibernate, например?



PS: нашел похожее обсуждение на stackoverflow: stackoverflow.com/questions/680320/django-orm-cach...

Answer 1

[Ололёша Ололоев]

Я так понимаю, весь код нужно выполнять в пределах одной транзакции. В джанго это осуществляется с помощью декоратора transaction (from django.db import transaction). И операция 3 не сможет быть выполнения пока, скажем, операция 4 не будет завершена.

Comments

[Ололёша Ололоев]

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

[stepank]

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

[stepank]

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

[Ололёша Ололоев]

Нет, если первая транзакция не завершится, то будет произведен откат и база будет находится в состоянии, в каком она было до начала транзакции.

[stepank]

на самом деле в проекте обновление происходит в одной транзации. т.е. сначала мы где-то вытаскиваем из БД объект в две разные переменные: 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 запрос неверное, вот и получается проблема

[Ололёша Ололоев]

Можно решить вопрос передачей в функцию id user и id transaction — и запрашивать актуальную информацию уже в функции

[stepank]

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

Answer 2

[ultimate_darkness]

По поводу второго вопроса. В Hibernate, если все операции происходят в рамках одной сессии (Hibernate Session), то transaction.account и user.accout вернут одну и ту же сущность, поэтому можно безопасно менять ее поля в разных местах кода.

Comments

[stepank]

да, спасибо. я в конце вопроса уже после его публикации добавил ссылку на похожий вопрос на stackoverflow. там как раз указывается, что Django ORM не предоаставляет функциональность identity map. если бы предоставлял, то вместе с транзакциями это уже было бы полностью рабочее решение

Answer 3

[Анатолий]

Может я что-то не понимаю, но судя по всему используется ActiveRecord и запись типа user.account.save() должна сохранить данные в бд, разве нет? Неважно откуда она вызывается, метод save должен сохранять текущие изменения обьекта в бд, иначе зачем он ввобще нужен?

Comments

[stepank]

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

Answer 4

[Suor]

Для одной операции не должно делаться манипуляций с аккаунтом в двух разных местах. Проблема в архитектуре кода, она дурная. Нужно просто посмотреть на всё вместе и срефакторить

Comments

[stepank]

если честно, я не понял Ваше предложение. одна и та же сущность вполне может меняться в разных местах системы — это нормально

Answer 5

[kmike]

Еще подумайте, вам точно нужна сущность «Account»? По сути же, насколько я понял, это просто кэш, чтоб из транзакций баланс не пересчитывать каждый раз. Вот и относитесь к ней, как к кэшу — те же подходы к инвалидации и тд. Может, даже пересчитывать каждый раз суммы на счете окажется ok, вы точно в это упираетесь по скорости?

Ну и, конечно, точка обновления счета должна быть одна: или какая-то явная функция, или по созданию Transaction пересчитывать значение в Account, или (imho плохо) по изменению Account создавать Transaction.

select_for_update есть в транке джанги. Для атомарного увеличения поля можно использовать F-объект (но лучше все пересчитывать целиком, опять же imho).

Comments

[stepank]

пересчитывать account на каждый чих — не вариант, это весьма ресурсоемкая операция, поэтому, видимо, все-таки эта сущность нужна

что касается точки обновления, она и так одна, есть у Account такой метод — update_balance. но как раз из вопроса должно быть понятно, что одновременно может существовать несколько питонячих объектов для одной записи БД. и вызов этого метода у разных объектов как раз и приведет к проблеме. а метод может вызываться в разных местах, это как раз нормально

про select for update — смотрите предыдущий ответ и мой комментарий к нему

вообще, наиболее грамотно принцип решения этой проблемы описан в обсуждении на stackoverflow, которое я привел в конце вопроса, он же упомянут ultimate_darkness на несколько ответов выше

[stepank]

а да, F-объект в некоторых случаях действительно помогает, хотя и немного загромождает код