librelist archives

« back to archive

How does flask.g work?

How does flask.g work?

From:
Methos
Date:
2014-09-12 @ 01:34
Hi,

I am new to flask, I read the documentation and thought I understood it.
I thought that if I put some variable in "flask.g", I would be able to
access it across requests.

In my web app, I want to read a config variable from DB and keep it in
"flask.g" so that it is not read again and again from DB.
For this, I wrote a similar function to get_db() function present
here: "http://flask.pocoo.org/docs/0.10/appcontext/"

I put a few debug messages to see if I am getting a cached copy of my
config var from "flask.g" or if I am reading again from DB.

What I see is that for each request, my code accesses DB again. The
cached copy of config variable does not persist across requests. I
searched a bit, and found following stackoverflow thread:
http://stackoverflow.com/questions/13617231/how-to-use-g-user-global-in-flask

It says that:
"g is a thread local and is per-request"
"while data set on g is only available for the lifetime of this request."


flask.g documentation says that:
"Just store on this whatever you want. For example a database
connection or the user that is currently logged in."

This made me think that one opens a DB connection, puts it in flask.g
to avoid reopening connections again and again.

Also, in general the documentation is very hard to understand at many
place. Is this some problem that only I am having?

1. " The application setup state in which the application implicitly
is on the module level."
What does this mean? I read it a few times, did not understand it.

2. "The main reason for the application’s context existence is that in
the past a bunch of functionality was attached to the request context
in lack of a better solution. Since one of the pillar’s of Flask’s
design is that you can have more than one application in the same
Python process.

So how does the code find the “right” application? In the past we
recommended passing applications around explicitly, but that caused
issues with libraries that were not designed with that in mind.

A common workaround for that problem was to use the current_app proxy
later on, which was bound to the current request’s application
reference. Since however creating such a request context is an
unnecessarily expensive operation in case there is no request around,
the application context was introduced."

I just joined the project. I have no clue what happened in the past.
Is it possible to explain these terms without referring to some past
designs/implementations?


3. "The application context is created and destroyed as necessary. It
never moves between threads and it will not be shared between
requests. As such it is the perfect place to store database connection
information and other things."
If application context is not shared between requests, how is it a
perfect place to store DB connections?
Would I not want my requests to share a DB connection?

4. In my view, I am trying to log something using
current_app.logger.debug("xxx")
But when I make a request to this view, it does not find current_app.
I thought it is supposed to be a proxy to app. I also tried using
"._get_current_object()", but that did not work either. Finally, I
just gave up and started using regular "print".

5. I read documentation for "Flask-Blueprint" and I am still not clear
why are they required.




I have a lot of programming experience but this is my first time
diving into web development. Since flask is a successful project and
many people have been using it, makes me think that either:

a. I am not reading correct documentation (in which case where should
I read most accurate documentation? I am reading it from:
http://flask.pocoo.org/docs/0.10/)

b. These concepts are all well known to web developers and I should
just know them. If that is the case, where can I get a primer? May be
read some Django tutorial?

c. Just forget the documentation and start reading code. Is this a
suggested approach?

Sorry for sounding agitated, but the documentation is totally obscure
to me (probably, my understanding is also affected due to lack of
sleep in last 40 hours. If everyone thinks that the documentation is
fine and it is the problem in my interpretation, then I apologize in
advance)

-M

Re: [flask] How does flask.g work?

From:
Charles
Date:
2014-09-12 @ 02:28
On Fri, Sep 12, 2014 at 8:34 AM, Methos <methos.oldest@gmail.com> wrote:
> Hi,
>
> I am new to flask, I read the documentation and thought I understood it.
> I thought that if I put some variable in "flask.g", I would be able to
> access it across requests.

I think it's between code modules in the same request. You put values
in flask.g to prevent having to pass it as arguments between
functions.

> In my web app, I want to read a config variable from DB and keep it in
> "flask.g" so that it is not read again and again from DB.
> For this, I wrote a similar function to get_db() function present
> here: "http://flask.pocoo.org/docs/0.10/appcontext/"

For this use I think you'll need to store it in a cache server, e.g.
using Flask-Cache or saving the value in redis.

> flask.g documentation says that:
> "Just store on this whatever you want. For example a database
> connection or the user that is currently logged in."

The practice is that database connection is opened on request and
closed when the request has been processed.

> This made me think that one opens a DB connection, puts it in flask.g
> to avoid reopening connections again and again.

For this you'll need to use a connection pool from the database
connector (if any) or use an external pooling server (like pgbouncer
if you are using postgresql).

> Also, in general the documentation is very hard to understand at many
> place. Is this some problem that only I am having?
>
> 1. " The application setup state in which the application implicitly
> is on the module level."

It means you are in some module where you have direct access to the
app = Flask(...) variable.

> I just joined the project. I have no clue what happened in the past.
> Is it possible to explain these terms without referring to some past
> designs/implementations?

Basically now we have two context, the application context and the
request context. The application context is used to store values
generic to all modules, like a database connection or cache storage.
The request context is used to store temporary values related to
current request. The application context is mostly used by flask
extension.

> 3. "The application context is created and destroyed as necessary. It
> never moves between threads and it will not be shared between
> requests. As such it is the perfect place to store database connection
> information and other things."
> If application context is not shared between requests, how is it a
> perfect place to store DB connections?
> Would I not want my requests to share a DB connection?

Each request should have their own database connection. DB connection
is created when the request begin and closed when the requests end.
This is also required because each connection have their own
transaction state, so we really cannot share the connection.

> 4. In my view, I am trying to log something using
> current_app.logger.debug("xxx")
> But when I make a request to this view, it does not find current_app.
> I thought it is supposed to be a proxy to app. I also tried using
> "._get_current_object()", but that did not work either. Finally, I
> just gave up and started using regular "print".

Will need to see the complete code on this. Normally

from flask import current_app
current_app.logger.debug('message')

just works


> 5. I read documentation for "Flask-Blueprint" and I am still not clear
> why are they required.

A flask application is really designed to be contained in a single
module, so if you are creating an application composed of a lot of
modules, you'll need a blueprint for each modules. Also the routes are
named based on the function name, so a blueprint will create a
namespace for the function names.

For example, if you want to add an admin section to you application
you can create an admin blueprint, so all the views will be contained
in the admin namespace. Furthermore you can attach a function that
will be run before requests in the blueprint, e.g. to check the user
authentication specific to that blueprint.

Re: [flask] How does flask.g work?

From:
Methos
Date:
2014-09-13 @ 17:54
Thank you. Your responses are really useful.
I appreciate taking time and answering my queries.

-M

On Thu, Sep 11, 2014 at 10:28 PM, Charles <peacech@gmail.com> wrote:
> On Fri, Sep 12, 2014 at 8:34 AM, Methos <methos.oldest@gmail.com> wrote:
>> Hi,
>>
>> I am new to flask, I read the documentation and thought I understood it.
>> I thought that if I put some variable in "flask.g", I would be able to
>> access it across requests.
>
> I think it's between code modules in the same request. You put values
> in flask.g to prevent having to pass it as arguments between
> functions.
>
>> In my web app, I want to read a config variable from DB and keep it in
>> "flask.g" so that it is not read again and again from DB.
>> For this, I wrote a similar function to get_db() function present
>> here: "http://flask.pocoo.org/docs/0.10/appcontext/"
>
> For this use I think you'll need to store it in a cache server, e.g.
> using Flask-Cache or saving the value in redis.
>
>> flask.g documentation says that:
>> "Just store on this whatever you want. For example a database
>> connection or the user that is currently logged in."
>
> The practice is that database connection is opened on request and
> closed when the request has been processed.
>
>> This made me think that one opens a DB connection, puts it in flask.g
>> to avoid reopening connections again and again.
>
> For this you'll need to use a connection pool from the database
> connector (if any) or use an external pooling server (like pgbouncer
> if you are using postgresql).
>
>> Also, in general the documentation is very hard to understand at many
>> place. Is this some problem that only I am having?
>>
>> 1. " The application setup state in which the application implicitly
>> is on the module level."
>
> It means you are in some module where you have direct access to the
> app = Flask(...) variable.
>
>> I just joined the project. I have no clue what happened in the past.
>> Is it possible to explain these terms without referring to some past
>> designs/implementations?
>
> Basically now we have two context, the application context and the
> request context. The application context is used to store values
> generic to all modules, like a database connection or cache storage.
> The request context is used to store temporary values related to
> current request. The application context is mostly used by flask
> extension.
>
>> 3. "The application context is created and destroyed as necessary. It
>> never moves between threads and it will not be shared between
>> requests. As such it is the perfect place to store database connection
>> information and other things."
>> If application context is not shared between requests, how is it a
>> perfect place to store DB connections?
>> Would I not want my requests to share a DB connection?
>
> Each request should have their own database connection. DB connection
> is created when the request begin and closed when the requests end.
> This is also required because each connection have their own
> transaction state, so we really cannot share the connection.
>
>> 4. In my view, I am trying to log something using
>> current_app.logger.debug("xxx")
>> But when I make a request to this view, it does not find current_app.
>> I thought it is supposed to be a proxy to app. I also tried using
>> "._get_current_object()", but that did not work either. Finally, I
>> just gave up and started using regular "print".
>
> Will need to see the complete code on this. Normally
>
> from flask import current_app
> current_app.logger.debug('message')
>
> just works
>
>
>> 5. I read documentation for "Flask-Blueprint" and I am still not clear
>> why are they required.
>
> A flask application is really designed to be contained in a single
> module, so if you are creating an application composed of a lot of
> modules, you'll need a blueprint for each modules. Also the routes are
> named based on the function name, so a blueprint will create a
> namespace for the function names.
>
> For example, if you want to add an admin section to you application
> you can create an admin blueprint, so all the views will be contained
> in the admin namespace. Furthermore you can attach a function that
> will be run before requests in the blueprint, e.g. to check the user
> authentication specific to that blueprint.