In this article by Joel Perras, author of the book Flask Blueprints, we will build our first fully functional, database-backed application. This application with the codename, Snap, will allow users to create an account with a username and password. In this account, users will be allowed to add, update, and delete the so-called semiprivate snaps of text (with a focus on lines of code) that can be shared with others.

For this you should be familiar with at least one of the following relational database systems: PostgreSQL, MySQL, or SQLite. Additionally, some knowledge of the SQLAlchemy Python library, which acts as an abstraction layer and object-relational mapper for these (and several other) databases, will be an asset. If you are not well versed in the usage of SQLAlchemy, fear not. We will have a gentle introduction to the library that will bring the new developers up to speed and serve as a refresher for the more experienced folks.

The SQLite database will be our relational database of choice due to its very simple installation and operation. The other database systems that we listed are all client/server-based with a multitude of configuration options that may need adjustment depending on the system they are installed in, while SQLite’s default mode of operation is self-contained, serverless, and zero-configuration.

Any major relational database supported by SQLAlchemy as a first-class citizen will do.

(For more resources related to this topic, see here.)

Diving In

To make sure things start correctly, let’s create a folder where this project will exist and a virtual environment to encapsulate any dependencies that we will require:

$ mkdir -p ~/src/snap && cd ~/src/snap

$ mkvirtualenv snap -i flask

This will create a folder called snap at the given path and take us to this newly created folder. It will then create the snap virtual environment and install Flask in this environment.

Remember that the mkvirtualenv tool will create the virtual environment, which will be the default set of locations to install the packages from pip, but the mkvirtualenv command does not create the project folder for you. This is why we will run a command to create the project folder first and then create the virtual environment. Virtual environments, by virtue of the $PATH manipulation performed once they are activated, are completely independent of where in your file system your project files exist.

We will then create our basic blueprint-based project layout with an empty users blueprint:

application

├── __init__.py

├── run.py

└── users

   ├── __init__.py

   ├── models.py

   └── views.py

Flask-SQLAlchemy

Once this has been established, we need to install the next important set of dependencies: SQLAlchemy, and the Flask extension that makes interacting with this library a bit more Flask-like, Flask-SQLAlchemy:

$ pip install flask-sqlalchemy

This will install the Flask extension to SQLAlchemy along with the base distribution of the latter and several other necessary dependencies in case they are not already present.

Now, if we were using a relational database system other than SQLite, this is the point where we would create the database entity in, say, PostgreSQL along with the proper users and permissions so that our application can create tables and modify the contents of these tables. SQLite, however, does not require any of that. Instead, it assumes that any user that has access to the filesystem location that the database is stored in should also have permission to modify the contents of this database.

For the sake of completeness, however, here is how one would create an empty database in the current folder of your filesystem:

$ sqlite3 snap.db # hit control-D to escape out of the interactive SQL console if necessary.

As mentioned previously, we will be using SQLite as the database for our example applications and the directions given will assume that SQLite is being used; the exact name of the binary may differ on your system. You can substitute the equivalent commands to create and administer the database of your choice if anything other than SQLite is being used.

Now, we can begin the basic configuration of the Flask-SQLAlchemy extension.

Configuring Flask-SQLAlchemy

First, we must register the Flask-SQLAlchemy extension with the application object in the application/__init__.py:

from flask import Flask

fromflask.ext.sqlalchemy import SQLAlchemy

 

app = Flask(__name__)

 

app.config['SQLALCHEMY_DATABASE_URI'] = 'sqlite:///../snap.db'

db = SQLAlchemy(app)

The value of app.config[‘SQLALCHEMY_DATABASE_URI’] is the escaped relative path to the snap.db SQLite database that we created previously. Once this simple configuration is in place, we will be able to create the SQLite database automatically via the db.create_all() method, which can be invoked in an interactive Python shell:

$ python

>>>from application import db

>>>db.create_all()

This should be an idempotent operation, which means that nothing would change even if the database already exists. If the local database file did not exist, however, it would be created. This also applies to adding new data models: running db.create_all() will add their definitions to the database, ensuring that the relevant tables have been created and are accessible. It does not, however, take into account the modification of an existing model/table definition that already exists in the database. For this, you will need to use the relevant tools (for example, the sqlite CLI) to modify the corresponding table definitions to match those that have been updated in your models or use a more general schema tracking and updating tool such as Alembic to do the majority of the heavy lifting for you.

SQLAlchemy basics

SQLAlchemy is, first and foremost, a toolkit to interact with the relational databases in Python.

While it provides an incredible number of features—including the SQL connection handling and pooling for various database engines, ability to handle custom datatypes, and a comprehensive SQL expression API—the one feature that most developers are familiar with is the Object Relational Mapper. This mapper allows a developer to connect a Python object definition to a SQL table in the database of their choice, thus allowing them the flexibility to control the domain models in their own application and requiring only minimal coupling to the database product and the engine-specific SQLisms that each of them exposes.

While debating the usefulness (or the lack thereof) of an object relational mapper is outside the scope of for those who are unfamiliar with SQLAlchemy we will provide a list of benefits that using this tool brings to the table, as follows:

• Your domain models are written to interface with one of the most well-respected, tested, and deployed Python packages ever created—SQLAlchemy.
• Onboarding new developers to a project becomes an order of magnitude easier due to the extensive documentation, tutorials, books, and articles that have been written about using SQLAlchemy.
• Import-time validation of queries written using the SQLAlchemy expression language; instead of having to execute each query string against the database to determine if there is a syntax error present. The expression language is in Python and can thus be validated with your usual set of tools and IDE.
• Thanks to the implementation of design patterns such as the Unit of Work, the Identity Map, and various lazy loading features, the developer can often be saved from performing more database/network roundtrips than necessary. Considering that the majority of a request/response cycle in a typical web application can easily be attributed to network latency of one form or another, minimizing the number of database queries in a typical response is a net performance win on many fronts.
• While many successful, performant applications can be built entirely on the ORM, SQLAlchemy does not force it upon you. If, for some reason, it is preferable to write raw SQL query strings or to use the SQLAlchemy expression language directly, then you can do that and still benefit from the connection pooling and the Python DBAPI abstraction functionality that is the core of SQLAlchemy itself.

Now that we’ve given you several reasons why you should be using this database query and domain data abstraction layer, let’s look at how we would go about defining a basic data model.

Summary

After having gone through this article we have seen several facets of how Flask may be augmented with the use of extensions. While Flask itself is relatively spartan, the ecology of extensions that are available make it such that building a fully fledged user-authenticated application may be done quickly and relatively painlessly.

Resources for Article:

Further resources on this subject:

• Creating Controllers with Blueprints[article]
• Deployment and Post Deployment [article]
• Man, Do I Like Templates! [article]