问题描述
好吧，我正在处理有关sqlalchemy和对象刷新的疑问！
Well, I am dealing with a doubt about sqlalchemy and objects refreshing!
我处于2个会话的状态，并且在两个会话中都查询了相同的对象！...对于某些特定的事情，我无法关闭其中一个会话.我已经修改了该对象并在会话A中提交了更改，但是在会话B中，属性是初始属性！未经修改！..
I am in the situation in what I have 2 sessions, and the same object has been queried in both sessions!... For some particular thing I cannot to close one of the sessions.I have modified the object and commited the changes in session A, but in session B, the attributes are the initial ones! without modifications!..
所以...我应该实现某种通知系统来传达更改，还是在sqlalchemy中有内置的方式来做到这一点?
So... shall I implement some kind of notification system to communicate changes or there is a built-in way to do this in sqlalchemy??
推荐答案
会话的设计就是这样.会话B中对象的属性将保持在会话B中首次查询时的状态.此外，SQLAlchemy不会在其他会话更改时尝试自动刷新对象，也不认为尝试创建某些对象是明智的像这样.
Sessions are designed to work like this. The attributes of the object in Session B WILL keep what it had when first queried in Session B. Additionally, SQLAlchemy will not attempt to automatically refresh objects in other sessions when they change, nor do I think it would be wise to try to create something like this.
您应该将每个会话的寿命视为数据库中的单个事务.会话如何以及何时需要处理其对象可能已过时这一事实，不是可以通过SQLAlchemy(或SQLAlchemy的任何扩展)中内置的算法解决的技术问题:这是一个业务"问题，您必须解决该问题确定并编写自己的代码. 正确"的响应可能是说这不是问题:如果会话B在会话B启动时使用了数据，则会话B发生的逻辑可能是有效的.您的问题"实际上可能不是问题.这些文档实际上具有完整介绍何时使用会话，但是如果您希望使用单一尺寸的安装，它会给出非常冷酷的响应-所有解决方案...
You should be actively thinking of the lifespan of each session as a single transaction in the database. How and when sessions need to deal with the fact that their objects might be stale is not a technical problem that can be solved by an algorithm built into SQLAlchemy (or any extension for SQLAlchemy): it is a "business" problem whose solution you must determine and code yourself. The "correct" response might be to say that this isn't a problem: the logic that occurs with Session B could be valid if it used the data at the time that Session B started. Your "problem" might not actually be a problem. The docs actually have an entire section on when to use sessions, but it gives a pretty grim response if you are hoping for a one-size-fits-all solution...
无论何时会话用于与数据库对话，它都会开始 数据库事务一开始就开始通信.假设 autocommit标志保留其建议的默认值False，这是 交易一直进行到会话回滚为止， 提交或关闭.会话将开始新的交易 在上一个事务结束之后再次使用；从 因此，该会话具有一定的使用寿命 跨很多交易，尽管一次只能进行一次.我们参考这些 事务范围和会话范围这两个概念.
The Session, whenever it is used to talk to the database, begins a database transaction as soon as it starts communicating. Assuming the autocommit flag is left at its recommended default of False, this transaction remains in progress until the Session is rolled back, committed, or closed. The Session will begin a new transaction if it is used again, subsequent to the previous transaction ending; from this it follows that the Session is capable of having a lifespan across many transactions, though only one at a time. We refer to these two concepts as transaction scope and session scope.
此处的含义是SQLAlchemy ORM鼓励 开发人员在他或她的应用程序中建立这两个范围， 不仅包括范围开始和结束的时间，还包括范围 这些范围中的一个，例如单个Session实例是否应该是本地的 函数或方法中的执行流，应该是 整个应用程序使用的全局对象，或者介于两者之间的某个位置 这两个.
The implication here is that the SQLAlchemy ORM is encouraging the developer to establish these two scopes in his or her application, including not only when the scopes begin and end, but also the expanse of those scopes, for example should a single Session instance be local to the execution flow within a function or method, should it be a global object used by the entire application, or somewhere in between these two.
开发人员确定此范围的负担是一个领域 SQLAlchemy ORM必定对如何 应该使用数据库.具体的工作模式单位 一种是随着时间的推移累积更改并定期刷新它们， 保持内存状态与已知状态同步 本地交易.此模式仅在有意义时有效 交易范围就位.
The burden placed on the developer to determine this scope is one area where the SQLAlchemy ORM necessarily has a strong opinion about how the database should be used. The unit of work pattern is specifically one of accumulating changes over time and flushing them periodically, keeping in-memory state in sync with what’s known to be present in a local transaction. This pattern is only effective when meaningful transaction scopes are in place.
也就是说，您可以做一些事情来改变情况的工作方式:
That said, there are a few things you can do to change how the situation works:
首先，您可以减少会话保持打开状态的时间.会话B正在查询对象，然后稍后您要对该对象(在同一会话中)执行某些操作，以使属性保持最新状态.一种解决方案是在单独的会话中完成第二个操作.
First, you can reduce how long your session stays open. Session B is querying the object, then later you are doing something with that object (in the same session) that you want to have the attributes be up to date. One solution is to have this second operation done in a separate session.
另一种方法是使用expire/refresh方法，如文档显示 ...
Another is to use the expire/refresh methods, as the docs show...
# 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()立即获取对象的最新版本，即使会话早先已经查询了该对象.
You can use session.refresh() to immediately get an up-to-date version of the object, even if the session already queried the object earlier.
这篇关于关于在sqlalchemy会话中刷新对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！