Sesje są zaprojektowane do tego celu . Atrybuty obiektu w sesji B ZACHOWAJĄ to, co miały podczas pierwszego zapytania w sesji B. Ponadto SQLAlchemy nie będzie próbował automatycznie odświeżyć obiektów w innych sesjach, gdy się zmienią, ani nie sądzę, że byłoby mądrze spróbować coś stworzyć w ten sposób.
Powinieneś aktywnie myśleć o długości życia każdej sesji jako pojedynczej transakcji w bazie danych. Jak i kiedy sesje muszą radzić sobie z faktem, że ich obiekty mogą być nieaktualne, nie jest problemem technicznym, który można rozwiązać za pomocą algorytmu wbudowanego w SQLAlchemy (lub dowolnego rozszerzenia SQLAlchemy):jest to problem „biznesowy”, którego rozwiązanie należy rozwiązać określić i zakodować siebie. „Właściwą” odpowiedzią może być stwierdzenie, że to nie jest problem:logika występująca w sesji B może być prawidłowa, jeśli używa danych w momencie rozpoczęcia sesji B. Twój „problem” może w rzeczywistości nie być problemem. Dokumenty faktycznie mają cała sekcja o tym, kiedy używać sesji , ale daje dość ponurą odpowiedź, jeśli liczysz na uniwersalne rozwiązanie...
To powiedziawszy, jest kilka rzeczy, które możesz zrobić, aby zmienić sposób działania tej sytuacji:
Po pierwsze, możesz skrócić czas, przez który sesja pozostaje otwarta. Sesja B wysyła zapytanie do obiektu, a później robisz coś z tym obiektem (w tej samej sesji), co chcesz, aby atrybuty były aktualne. Jednym z rozwiązań jest wykonanie tej drugiej operacji w osobnej sesji.
Innym jest użycie metod wygasania/odświeżania, jak w dokumentacji pokaż ...
# 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)
Możesz użyć session.refresh() aby natychmiast uzyskać aktualną wersję obiektu, nawet jeśli sesja już wcześniej odpytywała obiekt.
