Сесиите са проектирани да работят по този начин . Атрибутите на обекта в сесия B ЩЕ запазят това, което е имал при първото запитване в сесия B. Освен това SQLAlchemy няма да се опитва автоматично да обновява обекти в други сесии, когато се променят, нито мисля, че би било разумно да се опитате да създадете нещо така.
Трябва активно да мислите за продължителността на живота на всяка сесия като една транзакция в базата данни. Как и кога сесиите трябва да се справят с факта, че техните обекти може да са остарели, не е технически проблем, който може да бъде решен чрез алгоритъм, вграден в SQLAlchemy (или каквото и да е разширение за SQLAlchemy):това е "бизнес" проблем, чието решение трябва да определете и кодирайте сами. „Правилният“ отговор може да бъде да се каже, че това не е проблем:логиката, която възниква със сесия B, може да е валидна, ако използва данните в момента, в който сесия B е започнала. Вашият "проблем" може всъщност да не е проблем. Документите всъщност имат цял раздел за това кога да използвате сесиите , но дава доста мрачен отговор, ако се надявате на универсално решение...
Въпреки това има няколко неща, които можете да направите, за да промените начина, по който работи ситуацията:
Първо, можете да намалите колко дълго вашата сесия остава отворена. Сесия B прави заявка за обекта, след което по-късно правите нещо с този обект (в същата сесия), за което искате атрибутите да са актуални. Едно решение е тази втора операция да се извърши в отделна сесия.
Друг е да използвате методите expire/refresh, като документите показване ...
# immediately re-load attributes on obj1, obj2
session.refresh(obj1)
session.refresh(obj2)
# expire objects obj1, obj2, attributes will be reloaded
# on the next access:
session.expire(obj1)
session.expire(obj2)
Можете да използвате session.refresh() за да получите незабавно актуална версия на обекта, дори ако сесията вече е поискала обекта по-рано.
