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

[dborovikov]

Единственное правильно решение вашей проблемы — использование select for update. И да, что бы обезопасить себя от трудно уловимых ошибок стоит добавить поле с версией. Даже если не будет синхронизации, то по крайней мере транзакций откатится. Ну или использовать уровень изоляции SERIALIZATION, что тоже приведет к откату транзакции.

Comments

[stepank]

мб, я что-то не понимаю, но не похоже, что select for update может помочь, вот пример:

start transaction;
select * from transaction order by id limit 1 for update;
select * from transaction order by id limit 1 for update;
rollback;

очевидно, если между двумя запросами select новые данные в таблицу transacton не добавлялись, в выборку в обоих запросах попадет одна и та же запись. но, т.к. все это выполняется в пределах одной транзакции (а именно такая ситуация была в приложении), то никаких ошибок и блокировок не происходит. попытка сделать выборку этой записи из другой сессии, понятное дело, натыкается на блокировку и ждет, пока транзакция не будет завершена, но это не мой случай. хочется еще раз подчеркнуть, все операции, которые я описывал в изначальном вопросе происходили в рамках одной сессии и одной транзакции, поэтому select for update, видимо, не решение. по этим же причинам уровень изоляции SERIALIZABLE не поможет. кроме того, если я правильно понимаю, этот уровень сделает базу ощутимо менее проворной, что тоже не желательно

что касается отдельного поля для версии, это можно сделать, но его придется проверять явно, я правильно понимаю? если да, то это решение в общем-то не лучше того, чтобы просто вытаскивать запись еще раз перед вторым изменением

[dborovikov]

Если рассматривать одну сессию, то хороший ORM должен использовать identity-map и там проблемы вообще не существует — ORM не допустит что бы в одной сессии было два объекта с одним идентификатором. Если ваш ORM не умеет, то сочувствую :)

Насчет поля для версии — зависит от используемого ORM. Некоторые поддерживают из коробки. Все же я вам рекомендую иметь поле с версией в любом случае: оно будет сигналом для выявления ошибок.

Answer 6

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