That’s a really interesting approach, and I think I might try it. My concern here is whether I’m using things in the appropriate way. I think I’m failing to understand something about the way sqlalchemy works, and that’s the reason I’m asking this. For myself and for posterity. :)
-andrew > On Sep 4, 2016, at 11:22 AM, Michał Dobrzański <mike.dobrzan...@gmail.com> > wrote: > > 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 > <mailto: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 > <mailto:sqlalchemy+unsubscr...@googlegroups.com>. > To post to this group, send email to sqlalchemy@googlegroups.com > <mailto:sqlalchemy@googlegroups.com>. > Visit this group at https://groups.google.com/group/sqlalchemy > <https://groups.google.com/group/sqlalchemy>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > 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/kD2cccX6fzY/unsubscribe > <https://groups.google.com/d/topic/sqlalchemy/kD2cccX6fzY/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to > sqlalchemy+unsubscr...@googlegroups.com > <mailto:sqlalchemy+unsubscr...@googlegroups.com>. > To post to this group, send email to sqlalchemy@googlegroups.com > <mailto:sqlalchemy@googlegroups.com>. > Visit this group at https://groups.google.com/group/sqlalchemy > <https://groups.google.com/group/sqlalchemy>. > For more options, visit https://groups.google.com/d/optout > <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.
