Flask behind a design concept are two different "state" exists when the code is executed. Configuration state implicitly in the application layer module. It started Flask object is instantiated, and when the first incoming request, implicitly ends. When applied in this state, the following assumptions:
- Application programmers to modify objects safely.
- No request before any processing occurs.
- You need to use a reference to the object to modify it, no magic can give you a proxy you are creating or modifying the application object.
In contrast, at the time of request processing. Other rules exist:
- When the request is active when the local context objects (
flask.requestand other) points to the current request. - Any code can be found these objects at any time for use.
There is a third case, there is a little bit different. Sometimes, you are to interact with the application, even if the activity did not request a similar request when handled. Imagine the situation that you use the interactive Python shell interacts with the application, or a case of a command line application.
current_app Context of a local variable is the context-driven applications.
The purpose application context
The main reason is that the application context exists, in the past, there is no better way to attach a bunch of functions in the context of the request because one of the pillars Flask design is that you can have multiple applications in a Python process.
Then the code how to find the "right" application? In the past, we recommend explicitly passed around the application, but this does not cause a problem with this idea of the design of the library, because they allow libraries to realize this idea too inconvenient.
Common method is to solve the above problem will be mentioned later using current_app the agent, it is limited in application referenced current request. Since in any case create a costly operation of such a request context is not necessary in the absence of a request, then the introduction of the application context.
Create an application context
There are two ways to create an application context. The first is the implicit way: whenever a request context is pushed onto the stack, an application context will be created side by side, if this is necessary. Because of this result, you can ignore the existence of the context of the application, unless you need it.
The second way is to use explicit app_context() method:
from flask import Flask, current_app app = Flask(__name__) with app.app_context(): # within this block, current_app points to app. print current_app.name
If SERVER_NAME configured, it can also be used in the context of the application url_for() function. This also allows you to generate URLs even in the absence of a request.
Local variables of the application context
Application context is created and destroyed on demand. It does not move between threads, and will not be shared between requests. So, it is the best place to store a database connection information, or something else. Internal stack object is called flask._app_ctx_stack. Extension can be reversed at the top of the stack of free storage information, the premise is to use a unique name, flask.g the object is reserved for the user code.
For more information on this, see the Flask extension development .
Application context usage
Application context is usually used to cache resources under those created before to request or request usage. For example, a database connection is destined to use the application context. Application context should choose a unique name when storing things, because it is shared between a Flask application and extension of place.
The most common use is to resource management is divided into two parts:
- A resource implicit cache context.
- The context of a resource-based release of destruction.
In general, the get_X() function is used to create a resource X, if X otherwise it will return the same resources in the absence of teardown_X() a function registered as destroyed processor.
This is an example of connecting to the database:
import sqlite3
from flask import g def get_db(): db = getattr(g, '_database', None) if db is None: db = g._database = connect_to_database() return db @app.teardown_appcontext def teardown_db(exception): db = getattr(g, '_database', None) if db is not None: db.close()
The first call get_db() , the connection will be established. Establishment process implicitly uses a LocalProxy class:
from werkzeug.local import LocalProxy
db = LocalProxy(get_db)
In this way, the user can get_db() directly access to db the.