mirror of https://github.com/mitsuhiko/flask.git
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
78 lines
3.3 KiB
78 lines
3.3 KiB
.. _tutorial-dbcon: |
|
|
|
Step 3: Database Connections |
|
---------------------------- |
|
|
|
We have created a function for establishing a database connection with |
|
`connect_db` but by itself that's not particularly useful. Creating and |
|
closing database connections all the time is very inefficient, so we want |
|
to keep it around for longer. Because database connections encapsulate a |
|
transaction we also need to make sure that only one request at the time |
|
uses the connection. So how can we elegantly do that with Flask? |
|
|
|
This is where the application context comes into play. So let's start |
|
there. |
|
|
|
Flask provides us with two contexts: the application context and the |
|
request context. For the time being all you have to know is that there |
|
are special variables that use these. For instance the |
|
:data:`~flask.request` variable is the request object associated with |
|
the current request, whereas :data:`~flask.g` is a general purpose |
|
variable associated with the current application context. We will go into |
|
the details of this a bit later. |
|
|
|
For the time being all you have to know is that you can store information |
|
safely on the :data:`~flask.g` object. |
|
|
|
So when do you put it on there? To do that you can make a helper |
|
function. The first time the function is called it will create a database |
|
connection for the current context and successive calls will return the |
|
already established connection:: |
|
|
|
def get_db(): |
|
"""Opens a new database connection if there is none yet for the |
|
current application context. |
|
""" |
|
if not hasattr(g, 'sqlite_db'): |
|
g.sqlite_db = connect_db() |
|
return g.sqlite_db |
|
|
|
|
|
So now we know how to connect, but how do we properly disconnect? For |
|
that flask provides us with the :meth:`~flask.Flask.teardown_appcontext` |
|
decorator. It's executed every time the application context tears down:: |
|
|
|
@app.teardown_appcontext |
|
def close_db(error): |
|
"""Closes the database again at the end of the request.""" |
|
if hasattr(g, 'sqlite_db'): |
|
g.sqlite_db.close() |
|
|
|
Functions marked with :meth:`~flask.Flask.teardown_appcontext` are called |
|
every time the app context tears down. So what does this mean? |
|
Essentially the app context is created before the request comes in and is |
|
destroyed (teared down) whenever the request finishes. A teardown can |
|
happen because of two reasons: either everything went well (the error |
|
parameter will be `None`) or an exception happened in which case the error |
|
is passed to the teardown function. |
|
|
|
Curious about what these contexts mean? Have a look at the |
|
:ref:`app-context` documentation to learn more. |
|
|
|
Continue to :ref:`tutorial-dbinit`. |
|
|
|
.. hint:: Where do I put this code? |
|
|
|
If you've been following along in this tutorial, you might be wondering |
|
where to put the code from this step and the next. A logical place is to |
|
group these module-level functions together, and put your new |
|
``get_db`` and ``close_db`` functions below your existing |
|
``connect_db`` function (following the tutorial line-by-line). |
|
|
|
If you need a moment to find your bearings, take a look at how the `example |
|
source`_ is organized. In Flask, you can put all of your application code |
|
into a single Python module. You don't have to, and if your app :ref:`grows |
|
larger <larger-applications>`, it's a good idea not to. |
|
|
|
.. _example source: |
|
http://github.com/mitsuhiko/flask/tree/master/examples/flaskr/
|
|
|