For Pyramid application I cache engines in global variable under connection string keys. I cache engines when they're created. This way each time I need to use the engine I reach to that dictionary instead of creating it with each request.
On Sun, Sep 4, 2016 at 4:39 PM, Andrew Martin <agmar...@gmail.com> wrote: > I have a question about using creating engines along with pretty much any > python web framework, but I'm specifically working with Pyramid. For > obvious reasons. :) > > The sqlalchemy docs state this: > > "The typical usage of create_engine() > <http://docs.sqlalchemy.org/en/latest/core/engines.html#sqlalchemy.create_engine> > is > once per particular database URL, held globally for the lifetime of a > single application process. A single Engine > <http://docs.sqlalchemy.org/en/latest/core/connections.html#sqlalchemy.engine.Engine> > manages > many individual DBAPI connections on behalf of the process and is intended > to be called upon in a concurrent fashion. The Engine > <http://docs.sqlalchemy.org/en/latest/core/connections.html#sqlalchemy.engine.Engine> > is *not* synonymous to the DBAPI connect function, which represents just > one connection resource - the Engine > <http://docs.sqlalchemy.org/en/latest/core/connections.html#sqlalchemy.engine.Engine> > is > most efficient when created just once at the module level of an > application, not per-object or per-function call." > > But with most frameworks I've worked with--and with Pyramid > specifically--the best way to access the .ini settings is through the > request object, which means that the engine only lives for the lifetime of > the request? I think? > > I'm unsure about this. > > My sqlalchemy setup is a little weird (read: dumb) in the sense that I'm > not using the ORM layer at all. I use the engine to execute functions on a > postgres server which returns only a single json_aggs result. Then I either > make it a dict if it's going to a template or stick it as json if it's > going to an API that expects json. It probably sounds goofy, but it works > extremely well. And it's fast as hell. > > But I'm uncomfortable with the way I'm using engine_from_config. According > to the docs, I should create one and only one engine that exists for the > lifetime of the application. But the only reasonable way for me to access > the settings object is to go through a request object. And I know I must be > misunderstanding something here because, now that I think about it, there's > no effing way any web framework is reading the config from a .ini file for > every request. I mean, php would do that, but we are Python here. > > So, all that aside, what's the best way to do this? > > In my mind, if it's a per-request read of the settings, the it belongs > inside an object as part of the constructor. But if it's not, where do I > put it while keeping with best practices for web frameworks? > > -- > 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. > -- 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.
