I notice in the examples for flaskr you end up using flask.g.db to store the db object, However in the actual flask-website app that uses sqlalchemy, you do not use the g object. Why? -- Thadeus
Hi, On 2010-05-16 5:35 AM, Thadeus Burgess wrote: > I notice in the examples for flaskr you end up using flask.g.db to > store the db object, In g.db we store the *current* database connection. In SQLAlchemy there is a connection pool that is used in the background for you. When you are using the scoped_session it will use a database session and connection bound to the current thread, similar to how g itself works: http://bit.ly/b7dAYV Regards, Armin
So as long as my database supports connection pooling I am good. That is nice to know, thank you. -- Thadeus On Sun, May 16, 2010 at 3:52 AM, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 2010-05-16 5:35 AM, Thadeus Burgess wrote: >> I notice in the examples for flaskr you end up using flask.g.db to >> store the db object, > > In g.db we store the *current* database connection. In SQLAlchemy there > is a connection pool that is used in the background for you. > When you are using the scoped_session it will use a database session and > connection bound to the current thread, similar to how g itself works: > http://bit.ly/b7dAYV > > > Regards, > Armin >
If you are using scoped_session the sqlalchemy session is already thread-safe, and therefore does not need to be stored in the g object. On 16 May 2010 04:35, Thadeus Burgess <thadeusb@thadeusb.com> wrote: > I notice in the examples for flaskr you end up using flask.g.db to > store the db object, > > However in the actual flask-website app that uses sqlalchemy, you do > not use the g object. > > Why? > > -- > Thadeus >