> > well the engine is essentially a holder for a connection pool. If you use > a > pool like NullPool, it makes a new connection on every use, but in that > case > there is still not an official way to send in different connection > parameters. There’s no advantage to trying to make Engine work in a > different way, using two engines is just shorthand for using two different > sets of credentials. >
Ok. That makes sense. Thanks for clarifying. Definitely don’t need two sessionmakers, the engine can be passed both to > the constructor of Session directly as well as to the sessionmaker > function > at the moment the new Session is created. But it shouldn’t be any less > convenient to have two sessionmakers vs. passing two different engines in, > vs. passing connection credentials in somewhere when you need to connect. > There’s “two of something” going on no matter how you try to organize > that. > So I only need to select the relevant engine and pas to my )scoped) sessionmaker, then. Great. > I think what’s odd here is that if this is a web app, why is it needing to > maintain two sets of credentials internally in a single process for what > is > apparently the same database. > Some of the functions in the API allow arbitrary SQL strings to be passed for execution... but restricted access/views for reporting only. The API path is used to control server access, rather than exposing the database (postgres) to direct external connections. Postgres only listens on localhost. The implementation for these APIs then uses separate credentials to ensure read-only access in their implementation, whereas the vast majority of APIs have full access. Still odd? :) Thanks for the help, guys! Russ -- 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 http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
