On Thursday, March 26, 2020 at 2:53:08 PM UTC-4, Mike Bayer wrote:
>
> is the issue that your follower database is only updating
> asynchronously? I would likely organize the application to simply use two
> different Session objects, one for master one for follower. Trying to do
> it on a
On Thu, Mar 26, 2020, at 2:45 PM, Colton Allen wrote:
> Aside from disabling expire_on_commit, any thoughts on how I can prevent this
> error? I guess I just need a method to force the attribute refresh to use the
> master database. I'm just not sure where I should put that. Thoughts?
is the
Aside from disabling expire_on_commit, any thoughts on how I can prevent
this error? I guess I just need a method to force the attribute refresh to
use the master database. I'm just not sure where I should put that.
Thoughts?
I think one of my previous comments got lost because of
On Thu, Mar 26, 2020, at 2:18 PM, Colton Allen wrote:
> > You can adjust `expire_on_commit` if you're only doing short-term read-only
> > actions.
>
> Can you expand on this? Or link to docs/blog so I can do some research.
> Google hasn't helped me so far. Why would I want to expire after
By default, SqlAlchemy has `expire_on_commit=True`.
I'm going to poorly restate most of what Mike Bayer has told me in the
past: the rationale behind this- an active Session is supposed to mirror
the current state in the database; within a transaction we know the object
values are equal to
> You can adjust `expire_on_commit` if you're only doing short-term
read-only actions.
Can you expand on this? Or link to docs/blog so I can do some research.
Google hasn't helped me so far. Why would I want to expire after every
commit?
---
I agree with your assessment. I think its
My first guess is two things are going on:
1. This is a behavior of `expire_on_commit` on the session. Once you
commit on the Primary database, the object is stale.
https://docs.sqlalchemy.org/en/13/orm/session_api.html
2. The session is then trying to read off a Secondary database, but the
