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 formatting. Quoting it here for safety. "I agree with your assessment. I think its because every time I call "session". I'm actually saying "scoped_session(session_maker)()". So the _flushing attribute will be reset because its a new session instance." On Thursday, March 26, 2020 at 1:35:14 PM UTC-5, Mike Bayer wrote: > > > > 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 every > commit? > > > because once the transaction is completed, there are other transactions > going on in a database concurrently which can change the state of the > objects as they are represented in the database. in order that when you > next access these local objects so that they have the correct state, they > are automatically expired. However this behavior is not desirable in many > cases, so this flag is very commonly used to disable this behavior when you > are not concerned about your objects having stale data relative to other > transactions going on, when the new transaction begins. > > this behavior is described at: > https://docs.sqlalchemy.org/en/13/orm/session_basics.html#committing > > > > > > --- > > I agree with your assessment. I think its because every time I call > "session". I'm actually saying "session_maker()". So the _flushing > attribute will be reset because its a new session instance. > > On Thursday, March 26, 2020 at 1:02:18 PM UTC-5, Jonathan Vanasco wrote: > > 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 > row has not yet synced. > > You can adjust `expire_on_commit` if you're only doing short-term > read-only actions. However, I would explore to ensure this is trying to > read off the other database and why. > > > -- > SQLAlchemy - > The Python SQL Toolkit and Object Relational Mapper > > http://www.sqlalchemy.org/ > > To post example code, please provide an MCVE: Minimal, Complete, and > Verifiable Example. See http://stackoverflow.com/help/mcve for a full > description. > --- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlal...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sqlalchemy/8185b96d-35cb-4973-a9cf-1e572ebd643b%40googlegroups.com > > <https://groups.google.com/d/msgid/sqlalchemy/8185b96d-35cb-4973-a9cf-1e572ebd643b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/dd5c4d05-5af3-451e-b965-52ac50b432ac%40googlegroups.com.
