Sessioner er designet til at fungere som dette . Objektets attributter i Session B VIL beholde, hvad det havde, da det første gang blev forespurgt i Session B. Derudover vil SQLAlchemy ikke forsøge automatisk at opdatere objekter i andre sessioner, når de ændres, og jeg tror heller ikke, det ville være klogt at forsøge at skabe noget sådan her.
Du bør aktivt tænke på levetiden for hver session som en enkelt transaktion i databasen. Hvordan og hvornår sessioner skal håndtere det faktum, at deres objekter kan være forældede, er ikke et teknisk problem, der kan løses med en algoritme indbygget i SQLAlchemy (eller enhver udvidelse til SQLAlchemy):det er et "forretningsproblem", hvis løsning du skal bestemme og kode dig selv. Det "korrekte" svar kan være at sige, at dette ikke er et problem:den logik, der opstår med Session B, kunne være gyldig, hvis den brugte dataene på det tidspunkt, Session B startede. Dit "problem" er måske faktisk ikke et problem. Dokumenterne har faktisk en hele afsnittet om, hvornår man skal bruge sessioner , men det giver et ret dystert svar, hvis du håber på en løsning, der passer til alle...
Når det er sagt, er der et par ting, du kan gøre for at ændre, hvordan situationen fungerer:
For det første kan du reducere, hvor længe din session forbliver åben. Session B forespørger på objektet, så senere gør du noget med det objekt (i samme session), som du ønsker at have attributterne opdateret. En løsning er at få denne anden operation udført i en separat session.
En anden er at bruge expire/refresh-metoderne, som dokumenterne vis ...
# 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)
Du kan bruge session.refresh() for straks at få en opdateret version af objektet, selvom sessionen allerede forespurgte objektet tidligere.