Я борюсь с транзакциями в SQLAlchemy. Таким образом, очевидно, что всегда есть транзакция (если мы не используем autocommit=True
, которая устарела), и если кто-то хочет, чтобы материал был сохранен, нам нужно вызвать commit
, который, после сброса, создаст новую транзакцию в конце , Теперь моя проблема в том, что многие пользователи работают над базой кода, поэтому очень сложно сохранить контроль над транзакциями в первоначальном смысле. Представьте, что у нас есть что-то вроде этого:
db_session.begin_nested()
try:
method_that_triggers_a_lot()
except:
session.rollback()
session.commit()
Это работает только так, как ожидается, если у нас есть один или нет commit
, вызываемый при выполнении method_that_triggers_a_lot
. Я знаю об этом, но другие разработчики не могут. Так что, если кто-то добавит еще commit
где-то под method_that_triggers_a_lot
, я потеряю ожидаемое поведение. Я не совсем уверен, что если я что-то упустил, другие ORM, такие как doctrine, не сопровождаются транзакцией вокруг всего, поэтому вы должны явно объявить begin
, чтобы открыть ее. Поскольку это всегда происходит парами, вы никогда не потеряете ожидаемое поведение. Я читал, что мог бы использовать autocommit=True
, чтобы избавиться от автоматических c транзакций, но так как это помечено как устаревшее, мне интересно, есть ли лучший способ справиться с этим. Есть ли что-то вроде «именованных» транзакций, где я мог бы сделать что-то вроде
session.begin_nested("my_transaction")
try:
session.add(Whatever())
session.commit()
session.commit()
except:
session.rollback("my_transaction")
session.commit("my_transaction")
Из того, что я получил, ни subtransactions
, ни nested
здесь не могут помочь. Или есть безоговорочный способ работать без дефолтных транзакций вокруг всего?