Declaring Models¶
Generally Flask-SQLAlchemy behaves like a properly configured declarative
base from the declarative
extension. As such we
recommend reading the SQLAlchemy docs for a full reference. However the
most common use cases are also documented here.
Things to keep in mind:
The baseclass for all your models is called
db.Model
. It’s stored on the SQLAlchemy instance you have to create. See Quickstart for more details.Some parts that are required in SQLAlchemy are optional in Flask-SQLAlchemy. For instance the table name is automatically set for you unless overridden. It’s derived from the class name converted to lowercase and with “CamelCase” converted to “camel_case”. To override the table name, set the
__tablename__
class attribute.
Simple Example¶
A very simple example:
class User(db.Model):
id = db.Column(db.Integer, primary_key=True)
username = db.Column(db.String(80), unique=True, nullable=False)
email = db.Column(db.String(120), unique=True, nullable=False)
def __repr__(self):
return '<User %r>' % self.username
Use Column
to define a column. The name of the
column is the name you assign it to. If you want to use a different name
in the table you can provide an optional first argument which is a string
with the desired column name. Primary keys are marked with
primary_key=True
. Multiple keys can be marked as primary keys in
which case they become a compound primary key.
The types of the column are the first argument to
Column
. You can either provide them directly
or call them to further specify them (like providing a length). The
following types are the most common:
an integer |
|
a string with a maximum length (optional in some databases, e.g. PostgreSQL) |
|
some longer unicode text |
|
date and time expressed as Python
|
|
stores floating point values |
|
stores a boolean value |
|
stores a pickled Python object |
|
stores large arbitrary binary data |
One-to-Many Relationships¶
The most common relationships are one-to-many relationships. Because
relationships are declared before they are established you can use strings
to refer to classes that are not created yet (for instance if Person
defines a relationship to Address
which is declared later in the file).
Relationships are expressed with the relationship()
function. However the foreign key has to be separately declared with the
ForeignKey
class:
class Person(db.Model):
id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(50), nullable=False)
addresses = db.relationship('Address', backref='person', lazy=True)
class Address(db.Model):
id = db.Column(db.Integer, primary_key=True)
email = db.Column(db.String(120), nullable=False)
person_id = db.Column(db.Integer, db.ForeignKey('person.id'),
nullable=False)
What does db.relationship()
do?
That function returns a new property that can do multiple things.
In this case we told it to point to the Address
class and load
multiple of those. How does it know that this will return more than
one address? Because SQLAlchemy guesses a useful default from your
declaration. If you would want to have a one-to-one relationship you
can pass uselist=False
to relationship()
.
Since a person with no name or an email address with no address associated
makes no sense, nullable=False
tells SQLAlchemy to create the column
as NOT NULL
. This is implied for primary key columns, but it’s a good
idea to specify it for all other columns to make it clear to other people
working on your code that you did actually want a nullable column and did
not just forget to add it.
So what do backref
and lazy
mean? backref
is a simple way to also
declare a new property on the Address
class. You can then also use
my_address.person
to get to the person at that address. lazy
defines
when SQLAlchemy will load the data from the database:
'select'
/True
(which is the default, but explicit is better than implicit) means that SQLAlchemy will load the data as necessary in one go using a standard select statement.'joined'
/False
tells SQLAlchemy to load the relationship in the same query as the parent using aJOIN
statement.'subquery'
works like'joined'
but instead SQLAlchemy will use a subquery.'dynamic'
is special and can be useful if you have many items and always want to apply additional SQL filters to them. Instead of loading the items SQLAlchemy will return another query object which you can further refine before loading the items. Note that this cannot be turned into a different loading strategy when querying so it’s often a good idea to avoid using this in favor oflazy=True
. A query object equivalent to a dynamicuser.addresses
relationship can be created usingAddress.query.with_parent(user)
while still being able to use lazy or eager loading on the relationship itself as necessary.
How do you define the lazy status for backrefs? By using the
backref()
function:
class Person(db.Model):
id = db.Column(db.Integer, primary_key=True)
name = db.Column(db.String(50), nullable=False)
addresses = db.relationship('Address', lazy='select',
backref=db.backref('person', lazy='joined'))
Many-to-Many Relationships¶
If you want to use many-to-many relationships you will need to define a helper table that is used for the relationship. For this helper table it is strongly recommended to not use a model but an actual table:
tags = db.Table('tags',
db.Column('tag_id', db.Integer, db.ForeignKey('tag.id'), primary_key=True),
db.Column('page_id', db.Integer, db.ForeignKey('page.id'), primary_key=True)
)
class Page(db.Model):
id = db.Column(db.Integer, primary_key=True)
tags = db.relationship('Tag', secondary=tags, lazy='subquery',
backref=db.backref('pages', lazy=True))
class Tag(db.Model):
id = db.Column(db.Integer, primary_key=True)
Here we configured Page.tags
to be loaded immediately after loading
a Page, but using a separate query. This always results in two
queries when retrieving a Page, but when querying for multiple pages
you will not get additional queries.
The list of pages for a tag on the other hand is something that’s
rarely needed. For example, you won’t need that list when retrieving
the tags for a specific page. Therefore, the backref is set to be
lazy-loaded so that accessing it for the first time will trigger a
query to get the list of pages for that tag. If you need to apply
further query options on that list, you could either switch to the
'dynamic'
strategy - with the drawbacks mentioned above - or get
a query object using
Page.query.with_parent(some_tag)
and then use it exactly as you would with the query object from a dynamic
relationship.