Yeah, it seems to me that if you pass a *specific connection* to a sessionmaker for some (whatever) reason, that sessionmaker shouldn't ever silently take a different one.
I'll need to work on detecting or sabotaging new connections from a sessionmaker which was passed a specific connection. (I know the obvious question might be: why even use a sessionmaker/scoped session? and the answer is that those parts are all well buried in the framework, along with scopedsession.remove() call, so under certain circumstances only, I want the session to be guaranteed only one.) Any help on how to sabotage a sessionmaker/scoped_session to prevent later creation of a new connection would be appreciated. Thanks! On Thu, Apr 14, 2016 at 12:06 AM, Jonathan Vanasco <jonat...@findmeon.com> wrote: > > > On Wednesday, April 13, 2016 at 7:25:16 PM UTC-4, Mike Bayer wrote: >> >> Well scopedsession.remove throws away the session, so yeah either don't >> call that , or set up the connection immediately on the next session. > > > I thought "this is obvious, the session is closed on `remove`", but then > dug into the docs -- and I can see how this is misleading. > > The narrative docs ( > http://docs.sqlalchemy.org/en/latest/orm/session_api.html#session-and-sessionmaker > ) > > Session = sessionmaker() > # bind an individual session to a connectionsess = Session(bind=connection > > > It's easy to miss the importance of "individual" > > And then the API makes it seem like a bind(connection) would persist via > sessionmaker. > > > http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.sessionmaker.__init__ > > - *bind* > > <http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.sessionmaker.params.bind> > – > a Engine > > <http://docs.sqlalchemy.org/en/latest/core/connections.html#sqlalchemy.engine.Engine> > or > other Connectable > > <http://docs.sqlalchemy.org/en/latest/core/connections.html#sqlalchemy.engine.Connectable> > with > which newly createdSession > > <http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.Session> > objects > will be associated. > > > http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.Session > > > - *bind* > > <http://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.Session.params.bind> > – > An optional Engine > > <http://docs.sqlalchemy.org/en/latest/core/connections.html#sqlalchemy.engine.Engine> > or Connection > > <http://docs.sqlalchemy.org/en/latest/core/connections.html#sqlalchemy.engine.Connection> > to > which this Session should be bound. When specified, all SQL operations > performed by this session will execute via this connectable. > > > Unless one were more familiar, the `remove` behavior wouldn't be > apparent... and the notion of a particular connection being bound to a > Session Maker might seem like a good thing (it's actually not, because you > would inherently preclude the utility of connection pools , aside from > other effects) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "sqlalchemy" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/sqlalchemy/WcdRsvBTozk/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
