The Application Context

    This is similar to The Request Context, which keeps track of request-level data during a request. A corresponding application context is pushed when a request context is pushed.

    The application object has attributes, such as config, that are useful to access within views and . However, importing the instance within the modules in your project is prone to circular import issues. When using the app factory pattern or writing reusable or extensions there won’t be an app instance to import at all.

    Flask solves this issue with the application context. Rather than referring to an app directly, you use the proxy, which points to the application handling the current activity.

    Flask automatically pushes an application context when handling a request. View functions, error handlers, and other functions that run during a request will have access to current_app.

    Flask will also automatically push an app context when running CLI commands registered with using @app.cli.command().

    The application context is created and destroyed as necessary. When a Flask application begins handling a request, it pushes an application context and a request context. When the request ends it pops the request context then the application context. Typically, an application context will have the same lifetime as a request.

    If you try to access , or anything that uses it, outside an application context, you’ll get this error message:

    If you see that error while configuring your application, such as when initializing an extension, you can push a context manually since you have direct access to the app. Use app_context() in a block, and everything that runs in the block will have access to .

    If you see that error somewhere else in your code not related to configuring the application, it most likely indicates that you should move that code into a view function or CLI command.

    The application context is a good place to store common data during a request or CLI command. Flask provides the g object for this purpose. It is a simple namespace object that has the same lifetime as an application context.

    Note

    The g name stands for “global”, but that is referring to the data being global within a context. The data on g is lost after the context ends, and it is not an appropriate place to store data between requests. Use the or a database to store data across requests.

    1. teardown_X() closes or otherwise deallocates the resource if it exists. It is registered as a teardown_appcontext() handler.

    For example, you can manage a database connection using this pattern:

    During a request, every call to get_db() will return the same connection, and it will be closed automatically at the end of the request.

    You can use to make a new context local from get_db():

    Accessing db will call internally, in the same way that current_app works.

    If is true, the following signals are sent: appcontext_pushed, , and appcontext_popped.