5

According to the answer given in Is it safe to store per-request data on flask.request? it seems that the g object is request-local (= has the lifetime of a single request). Maybe I misunderstood this answer, but the Flask documentation states that the g object would be global which seems to contradict this answer.

The documentation itself is a bit short about these details, so please would you mind to explain the details to the contexts and the global object g? Specifically to address the following questions:

  1. In order to store data for the lifetime of a single request, how should that be done? (Using the request object, the g object or which kind of object?)
  2. In order to store data for the lifetime of an application, how should that be done? (Using the app object, the g object or which kind of object?)
  3. Flask could be used in a multi-process environment. Is it correct to assume that in such a mode of operation there will be multiple application-wide objects? (This would imply that all of these app or g objects then need to be initialized individually for the lifetime of each worker process.)
  4. Related to question 3: If I require an application wide, single singleton-like object that provides services to a Flask web application, it is mandatory to factor out this service into an external process? (Within a multi-process mode of operation there won't be a single singleton-like instance?)
Regis May
  • 3,070
  • 2
  • 30
  • 51

1 Answers1

9

In order to store data for the lifetime of a single request, how should that be done?

The g object is designed for this. The documentation states:

Flask provides you with a special object that ensures it is only valid for the active request and that will return different values for each request.

Although the documentation refers to g as "global", that's not really accurate - "thread-global" would be better.

In order to store data for the lifetime of an application, how should that be done?

I think the answer to this question answers this as well (or better) than I could: Preserving global state in a flask application

Flask could be used in a multi-process environment. Is it correct to assume that in such a mode of operation there will be multiple application-wide objects? (This would imply that all of these app or g objects then need to be initialized individually for the lifetime of each worker process.)

In a multi-process environment, each request is handled as a seperate thread, and g is intialized and destroyed on a per-request basis, so there will be as many concurrent g object as threads - though each thread can only see it's own. In most scenarios I suspect there should only ever one app object, an instance of the Flask() class created by the programmer, i.e. app = Flask(__name__) or similar.

Blueprints and Application Dispatching are two way of having "multiple" application objects, in as far as you have multiple applications running concurrently.

jfowkes
  • 1,495
  • 9
  • 17
  • 1
    Let me point out that in one detail you provide me with the same confusion as the answer I referred to: The `g` object seems to be related to an application context so it would maintain data for longer than a single request. That's one of the reasons why I'm asking part 1 of my question. Answer 19277280 states that I have `g` on a request basis. That confuses me as well: In the Flask documentation I find an example about storing open data base connections in `g`, which then would make no sense. – Regis May Sep 21 '18 at 13:09
  • 1
    Do you mean the example at the end of http://flask.pocoo.org/docs/1.0/appcontext/? The database connection there only exists for the lifetime of the context. – jfowkes Sep 21 '18 at 14:27