orbit-oss/flask
4
4
Fork 2
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Updated documentation to use teardown request where appropriate

Browse source
This commit is contained in:
Armin Ronacher 2011-05-27 20:21:41 +02:00
parent ba6bf23e0d
commit a9fc040c39
4 changed files with 45 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

31
docs/tutorial/dbcon.rst
View file

@ -9,22 +9,8 @@ connection in all our functions so it makes sense to initialize them
before each request and shut them down afterwards.
Flask allows us to do that with the :meth:`~flask.Flask.before_request`,
:meth:`~flask.Flask.after_request` and :meth:`~flask.Flask.teardown_request`
decorators. In debug mode, if an error is raised,
:meth:`~flask.Flask.after_request` won't be run, and you'll have access to the
db connection in the interactive debugger::
@app.before_request
def before_request():
g.db = connect_db()
@app.after_request
def after_request(response):
g.db.close()
return response
If you want to guarantee that the connection is always closed in debug mode, you
can close it in a function decorated with :meth:`~flask.Flask.teardown_request`::
:meth:`~flask.Flask.teardown_request` and :meth:`~flask.Flask.teardown_request`
decorators::
@app.before_request
def before_request():
@ -36,18 +22,17 @@ can close it in a function decorated with :meth:`~flask.Flask.teardown_request`:
Functions marked with :meth:`~flask.Flask.before_request` are called before
a request and passed no arguments. Functions marked with
:meth:`~flask.Flask.after_request` are called after a request and
:meth:`~flask.Flask.teardown_request` are called after a request and
passed the response that will be sent to the client. They have to return
that response object or a different one. In this case we just return it
unchanged.
Functions marked with :meth:`~flask.Flask.teardown_request` get called after the
that response object or a different one. They are however not guaranteed
to be executed if an exception is raised, this is where functions marked with
:meth:`~flask.Flask.teardown_request` come in. They get called after the
response has been constructed. They are not allowed to modify the request, and
their return values are ignored. If an exception occurred while the request was
being processed, it is passed to each function; otherwise, None is passed in.
being processed, it is passed to each function; otherwise, `None` is passed in.
We store our current database connection on the special :data:`~flask.g`
object that flask provides for us. This object stores information for one
object that Flask provides for us. This object stores information for one
request only and is available from within each function. Never store such
things on other objects because this would not work with threaded
environments. That special :data:`~flask.g` object does some magic behind