Object Relational Tutorial

The SQLAlchemy Object Relational Mapper presents a method of associatinguser-defined Python classes with database tables, and instances of thoseclasses (objects) with rows in their corresponding tables. It includes asystem that transparently synchronizes all changes in state between objectsand their related rows, called a unit of work, as well as a systemfor expressing database queries in terms of the user defined classes and theirdefined relationships between each other.

The ORM is in contrast to the SQLAlchemy Expression Language, upon which theORM is constructed. Whereas the SQL Expression Language, introduced inSQL Expression Language Tutorial, presents a system of representing the primitiveconstructs of the relational database directly without opinion, the ORMpresents a high level and abstracted pattern of usage, which itself is anexample of applied usage of the Expression Language.

While there is overlap among the usage patterns of the ORM and the ExpressionLanguage, the similarities are more superficial than they may at first appear.One approaches the structure and content of data from the perspective of auser-defined domain model which is transparentlypersisted and refreshed from its underlying storage model. The otherapproaches it from the perspective of literal schema and SQL expressionrepresentations which are explicitly composed into messages consumedindividually by the database.

A successful application may be constructed using the Object Relational Mapperexclusively. In advanced situations, an application constructed with the ORMmay make occasional usage of the Expression Language directly in certain areaswhere specific database interactions are required.

The following tutorial is in doctest format, meaning each >>> linerepresents something you can type at a Python command prompt, and thefollowing text represents the expected return value.

Version Check

A quick check to verify that we are on at least version 1.3 of SQLAlchemy:

  1. >>> import sqlalchemy
  2. >>> sqlalchemy.__version__
  3. 1.3.0

Connecting

For this tutorial we will use an in-memory-only SQLite database. To connect weuse create_engine():

  1. >>> from sqlalchemy import create_engine
  2. >>> engine = create_engine('sqlite:///:memory:', echo=True)

The echo flag is a shortcut to setting up SQLAlchemy logging, which isaccomplished via Python’s standard logging module. With it enabled, we’llsee all the generated SQL produced. If you are working through this tutorialand want less output generated, set it to False. This tutorial will formatthe SQL behind a popup window so it doesn’t get in our way; just click the“SQL” links to see what’s being generated.

The return value of create_engine() is an instance ofEngine, and it represents the core interface to thedatabase, adapted through a dialect that handles the detailsof the database and DBAPI in use. In this case the SQLitedialect will interpret instructions to the Python built-in sqlite3module.

Lazy Connecting

The Engine, when first returned by create_engine(),has not actually tried to connect to the database yet; that happensonly the first time it is asked to perform a task against the database.

The first time a method like Engine.execute() or Engine.connect()is called, the Engine establishes a real DBAPI connection to thedatabase, which is then used to emit the SQL. When using the ORM, we typicallydon’t use the Engine directly once created; instead, it’s usedbehind the scenes by the ORM as we’ll see shortly.

See also

Database Urls - includes examples of create_engine()connecting to several kinds of databases with links to more information.

Declare a Mapping

When using the ORM, the configurational process starts by describing the databasetables we’ll be dealing with, and then by defining our own classes which willbe mapped to those tables. In modern SQLAlchemy,these two tasks are usually performed together,using a system known as Declarative, which allows us to createclasses that include directives to describe the actual database table they willbe mapped to.

Classes mapped using the Declarative system are defined in terms of a base class whichmaintains a catalog of classes andtables relative to that base - this is known as the declarative base class. Ourapplication will usually have just one instance of this base in a commonlyimported module. We create the base class using the declarative_base()function, as follows:

  1. >>> from sqlalchemy.ext.declarative import declarative_base
  2.  
  3. >>> Base = declarative_base()

Now that we have a “base”, we can define any number of mapped classes in termsof it. We will start with just a single table called users, which will storerecords for the end-users using our application.A new class called User will be the class to which we map this table. Withinthe class, we define details about the table to which we’ll be mapping, primarilythe table name, and names and datatypes of columns:

  1. >>> from sqlalchemy import Column, Integer, String
  2. >>> class User(Base):
  3. ... __tablename__ = 'users'
  4. ...
  5. ... id = Column(Integer, primary_key=True)
  6. ... name = Column(String)
  7. ... fullname = Column(String)
  8. ... nickname = Column(String)
  9. ...
  10. ... def __repr__(self):
  11. ... return "<User(name='%s', fullname='%s', nickname='%s')>" % (
  12. ... self.name, self.fullname, self.nickname)

Tip

The User class defines a repr() method,but note that is optional; we only implement it inthis tutorial so that our examples show nicelyformatted User objects.

A class using Declarative at a minimumneeds a tablename attribute, and at least oneColumn which is part of a primary key 1. SQLAlchemy never makes anyassumptions by itself about the table to whicha class refers, including that it has no built-in conventions for names,datatypes, or constraints. But this doesn’t meanboilerplate is required; instead, you’re encouraged to create yourown automated conventions using helper functions and mixin classes, whichis described in detail at Mixin and Custom Base Classes.

When our class is constructed, Declarative replaces all the Columnobjects with special Python accessors known as descriptors; this is aprocess known as instrumentation. The “instrumented” mapped classwill provide us with the means to refer to our table in a SQL context as wellas to persist and load the values of columns from the database.

Outside of what the mapping process does to our class, the class remainsotherwise mostly a normal Python class, to which we can define anynumber of ordinary attributes and methods needed by our application.

Create a Schema

With our User class constructed via the Declarative system, we have defined information aboutour table, known as table metadata. The object used by SQLAlchemy to representthis information for a specific table is called the Table object, and here Declarative has madeone for us. We can see this object by inspecting the table attribute:

  1. >>> User.__table__
  2. Table('users', MetaData(bind=None),
  3. Column('id', Integer(), table=<users>, primary_key=True, nullable=False),
  4. Column('name', String(), table=<users>),
  5. Column('fullname', String(), table=<users>),
  6. Column('nickname', String(), table=<users>), schema=None)

Classical Mappings

The Declarative system, though highly recommended,is not required in order to use SQLAlchemy’s ORM.Outside of Declarative, anyplain Python class can be mapped to any Tableusing the mapper() function directly; thisless common usage is described at Classical Mappings.

When we declared our class, Declarative used a Python metaclass in order toperform additional activities once the class declaration was complete; withinthis phase, it then created a Table object according to ourspecifications, and associated it with the class by constructinga Mapper object. This object is a behind-the-scenes object we normallydon’t need to deal with directly (though it can provide plenty of informationabout our mapping when we need it).

The Table object is a member of a larger collectionknown as MetaData. When using Declarative,this object is available using the .metadataattribute of our declarative base class.

The MetaDatais a registry which includes the ability to emit a limited setof schema generation commands to the database. As our SQLite databasedoes not actually have a users table present, we can use MetaDatato issue CREATE TABLE statements to the database for all tables that don’t yet exist.Below, we call the MetaData.create_all() method, passing in our Engineas a source of database connectivity. We will see that special commands arefirst emitted to check for the presence of the users table, and following thatthe actual CREATE TABLE statement:

  1. >>> Base.metadata.create_all(engine)
  2. SELECT ...
  3. PRAGMA main.table_info("users")
  4. ()
  5. PRAGMA temp.table_info("users")
  6. ()
  7. CREATE TABLE users (
  8. id INTEGER NOT NULL, name VARCHAR,
  9. fullname VARCHAR,
  10. nickname VARCHAR,
  11. PRIMARY KEY (id)
  12. )
  13. ()
  14. COMMIT

Minimal Table Descriptions vs. Full Descriptions

Users familiar with the syntax of CREATE TABLE may notice that theVARCHAR columns were generated without a length; on SQLite and PostgreSQL,this is a valid datatype, but on others, it’s not allowed. So if runningthis tutorial on one of those databases, and you wish to use SQLAlchemy toissue CREATE TABLE, a “length” may be provided to the String type asbelow:

  1. Column(String(50))

The length field on String, as well as similar precision/scale fieldsavailable on Integer, Numeric, etc. are not referenced bySQLAlchemy other than when creating tables.

Additionally, Firebird and Oracle require sequences to generate newprimary key identifiers, and SQLAlchemy doesn’t generate or assume thesewithout being instructed. For that, you use the Sequence construct:

  1. from sqlalchemy import Sequence
  2. Column(Integer, Sequence('user_id_seq'), primary_key=True)

A full, foolproof Table generated via our declarativemapping is therefore:

  1. class User(Base):
  2. __tablename__ = 'users'
  3. id = Column(Integer, Sequence('user_id_seq'), primary_key=True)
  4. name = Column(String(50))
  5. fullname = Column(String(50))
  6. nickname = Column(String(50))
  7.  
  8. def __repr__(self):
  9. return "<User(name='%s', fullname='%s', nickname='%s')>" % (
  10. self.name, self.fullname, self.nickname)

We include this more verbose table definition separatelyto highlight the difference between a minimal construct geared primarilytowards in-Python usage only, versus one that will be used to emit CREATETABLE statements on a particular set of backends with more stringentrequirements.

Create an Instance of the Mapped Class

With mappings complete, let’s now create and inspect a User object:

  1. >>> ed_user = User(name='ed', fullname='Ed Jones', nickname='edsnickname')
  2. >>> ed_user.name
  3. 'ed'
  4. >>> ed_user.nickname
  5. 'edsnickname'
  6. >>> str(ed_user.id)
  7. 'None'

the init() method

Our User class, as defined using the Declarative system, hasbeen provided with a constructor (e.g. init() method) which automaticallyaccepts keyword names that match the columns we’ve mapped. We are freeto define any explicit init() method we prefer on our class, whichwill override the default method provided by Declarative.

Even though we didn’t specify it in the constructor, the id attributestill produces a value of None when we access it (as opposed to Python’susual behavior of raising AttributeError for an undefined attribute).SQLAlchemy’s instrumentation normally produces this default value forcolumn-mapped attributes when first accessed. For those attributes wherewe’ve actually assigned a value, the instrumentation system is trackingthose assignments for use within an eventual INSERT statement to be emitted to thedatabase.

Creating a Session

We’re now ready to start talking to the database. The ORM’s “handle” to thedatabase is the Session. When we first set upthe application, at the same level as our create_engine()statement, we define a Session class whichwill serve as a factory for new Sessionobjects:

  1. >>> from sqlalchemy.orm import sessionmaker
  2. >>> Session = sessionmaker(bind=engine)

In the case where your application does not yet have anEngine when you define your module-levelobjects, just set it up like this:

  1. >>> Session = sessionmaker()

Later, when you create your engine with create_engine(),connect it to the Session usingconfigure():

  1. >>> Session.configure(bind=engine) # once engine is available

Session Lifecycle Patterns

The question of when to make a Session depends a lot on whatkind of application is being built. Keep in mind,the Session is just a workspace for your objects,local to a particular database connection - if you think ofan application thread as a guest at a dinner party, the Sessionis the guest’s plate and the objects it holds are the food(and the database…the kitchen?)! More on this topicavailable at When do I construct a Session, when do I commit it, and when do I close it?.

This custom-made Session class will createnew Session objects which are bound to ourdatabase. Other transactional characteristics may be defined when callingsessionmaker as well; these are described in a laterchapter. Then, whenever you need to have a conversation with the database, youinstantiate a Session:

  1. >>> session = Session()

The above Session is associated with ourSQLite-enabled Engine, but it hasn’t opened any connections yet. When it’s firstused, it retrieves a connection from a pool of connections maintained by theEngine, and holds onto it until we commit all changes and/or close thesession object.

Adding and Updating Objects

To persist our User object, we add() it to our Session:

  1. >>> ed_user = User(name='ed', fullname='Ed Jones', nickname='edsnickname')
  2. >>> session.add(ed_user)

At this point, we say that the instance is pending; no SQL has yet been issuedand the object is not yet represented by a row in the database. TheSession will issue the SQL to persist EdJones as soon as is needed, using a process known as a flush. If wequery the database for Ed Jones, all pending information will first beflushed, and the query is issued immediately thereafter.

For example, below we create a new Query objectwhich loads instances of User. We “filter by” the name attribute ofed, and indicate that we’d like only the first result in the full list ofrows. A User instance is returned which is equivalent to that which we’veadded:

  1. sql>>> our_user = session.query(User).filter_by(name='ed').first()
  2. BEGIN (implicit)
  3. INSERT INTO users (name, fullname, nickname) VALUES (?, ?, ?)
  4. ('ed', 'Ed Jones', 'edsnickname')
  5. SELECT users.id AS users_id,
  6. users.name AS users_name,
  7. users.fullname AS users_fullname,
  8. users.nickname AS users_nickname
  9. FROM users
  10. WHERE users.name = ?
  11. LIMIT ? OFFSET ?
  12. ('ed', 1, 0)
  13. >>> our_user
  14. <User(name='ed', fullname='Ed Jones', nickname='edsnickname')>

In fact, the Session has identified that therow returned is the same row as one already represented within itsinternal map of objects, so we actually got back the identical instance asthat which we just added:

  1. >>> ed_user is our_user
  2. True

The ORM concept at work here is known as an identity mapand ensures thatall operations upon a particular row within aSession operate upon the same set of data.Once an object with a particular primary key is present in theSession, all SQL queries on thatSession will always return the same Pythonobject for that particular primary key; it also will raise an error if anattempt is made to place a second, already-persisted object with the sameprimary key within the session.

We can add more User objects at once usingadd_all():

  1. >>> session.add_all([
  2. ... User(name='wendy', fullname='Wendy Williams', nickname='windy'),
  3. ... User(name='mary', fullname='Mary Contrary', nickname='mary'),
  4. ... User(name='fred', fullname='Fred Flintstone', nickname='freddy')])

Also, we’ve decided Ed’s nickname isn’t that great, so lets change it:

  1. >>> ed_user.nickname = 'eddie'

The Session is paying attention. It knows,for example, that Ed Jones has been modified:

  1. >>> session.dirty
  2. IdentitySet([<User(name='ed', fullname='Ed Jones', nickname='eddie')>])

and that three new User objects are pending:

  1. >>> session.new
  2. IdentitySet([<User(name='wendy', fullname='Wendy Williams', nickname='windy')>,
  3. <User(name='mary', fullname='Mary Contrary', nickname='mary')>,
  4. <User(name='fred', fullname='Fred Flintstone', nickname='freddy')>])

We tell the Session that we’d like to issueall remaining changes to the database and commit the transaction, which hasbeen in progress throughout. We do this via commit(). TheSession emits the UPDATE statementfor the nickname change on “ed”, as well as INSERT statements for thethree new User objects we’ve added:

  1. sql>>> session.commit()
  2. UPDATE users SET nickname=? WHERE users.id = ?
  3. ('eddie', 1)
  4. INSERT INTO users (name, fullname, nickname) VALUES (?, ?, ?)
  5. ('wendy', 'Wendy Williams', 'windy')
  6. INSERT INTO users (name, fullname, nickname) VALUES (?, ?, ?)
  7. ('mary', 'Mary Contrary', 'mary')
  8. INSERT INTO users (name, fullname, nickname) VALUES (?, ?, ?)
  9. ('fred', 'Fred Flintstone', 'freddy')
  10. COMMIT

commit() flushes the remaining changes to thedatabase, and commits the transaction. The connection resources referenced bythe session are now returned to the connection pool. Subsequent operationswith this session will occur in a new transaction, which will againre-acquire connection resources when first needed.

If we look at Ed’s id attribute, which earlier was None, it now has a value:

  1. sql>>> ed_user.id
  2. BEGIN (implicit)
  3. SELECT users.id AS users_id,
  4. users.name AS users_name,
  5. users.fullname AS users_fullname,
  6. users.nickname AS users_nickname
  7. FROM users
  8. WHERE users.id = ?
  9. (1,)
  10. 1

After the Session inserts new rows in thedatabase, all newly generated identifiers and database-generated defaultsbecome available on the instance, either immediately or viaload-on-first-access. In this case, the entire row was re-loaded on accessbecause a new transaction was begun after we issued commit(). SQLAlchemyby default refreshes data from a previous transaction the first time it’saccessed within a new transaction, so that the most recent state is available.The level of reloading is configurable as is described in Using the Session.

Session Object States

As our User object moved from being outside the Session, toinside the Session without a primary key, to actually beinginserted, it moved between three out of fouravailable “object states” - transient, pending, and persistent.Being aware of these states and what they mean is always a good idea -be sure to read Quickie Intro to Object States for a quick overview.

Rolling Back

Since the Session works within a transaction,we can roll back changes made too. Let’s make two changes that we’ll revert;ed_user’s user name gets set to Edwardo:

  1. >>> ed_user.name = 'Edwardo'

and we’ll add another erroneous user, fake_user:

  1. >>> fake_user = User(name='fakeuser', fullname='Invalid', nickname='12345')
  2. >>> session.add(fake_user)

Querying the session, we can see that they’re flushed into the current transaction:

  1. sql>>> session.query(User).filter(User.name.in_(['Edwardo', 'fakeuser'])).all()
  2. UPDATE users SET name=? WHERE users.id = ?
  3. ('Edwardo', 1)
  4. INSERT INTO users (name, fullname, nickname) VALUES (?, ?, ?)
  5. ('fakeuser', 'Invalid', '12345')
  6. SELECT users.id AS users_id,
  7. users.name AS users_name,
  8. users.fullname AS users_fullname,
  9. users.nickname AS users_nickname
  10. FROM users
  11. WHERE users.name IN (?, ?)
  12. ('Edwardo', 'fakeuser')
  13. [<User(name='Edwardo', fullname='Ed Jones', nickname='eddie')>, <User(name='fakeuser', fullname='Invalid', nickname='12345')>]

Rolling back, we can see that ed_user’s name is back to ed, andfake_user has been kicked out of the session:

  1. sql>>> session.rollback()
  2. ROLLBACK
  3.  
  4. sql>>> ed_user.name
  5. BEGIN (implicit)
  6. SELECT users.id AS users_id,
  7. users.name AS users_name,
  8. users.fullname AS users_fullname,
  9. users.nickname AS users_nickname
  10. FROM users
  11. WHERE users.id = ?
  12. (1,)
  13. u'ed'
  14. >>> fake_user in session
  15. False

issuing a SELECT illustrates the changes made to the database:

  1. sql>>> session.query(User).filter(User.name.in_(['ed', 'fakeuser'])).all()
  2. SELECT users.id AS users_id,
  3. users.name AS users_name,
  4. users.fullname AS users_fullname,
  5. users.nickname AS users_nickname
  6. FROM users
  7. WHERE users.name IN (?, ?)
  8. ('ed', 'fakeuser')
  9. [<User(name='ed', fullname='Ed Jones', nickname='eddie')>]

Querying

A Query object is created using thequery() method onSession. This function takes a variablenumber of arguments, which can be any combination of classes andclass-instrumented descriptors. Below, we indicate aQuery which loads User instances. Whenevaluated in an iterative context, the list of User objects present isreturned:

  1. sql>>> for instance in session.query(User).order_by(User.id):
  2. ... print(instance.name, instance.fullname)
  3. SELECT users.id AS users_id,
  4. users.name AS users_name,
  5. users.fullname AS users_fullname,
  6. users.nickname AS users_nickname
  7. FROM users ORDER BY users.id
  8. ()
  9. ed Ed Jones
  10. wendy Wendy Williams
  11. mary Mary Contrary
  12. fred Fred Flintstone

The Query also accepts ORM-instrumenteddescriptors as arguments. Any time multiple class entities or column-basedentities are expressed as arguments to thequery() function, the return resultis expressed as tuples:

  1. sql>>> for name, fullname in session.query(User.name, User.fullname):
  2. ... print(name, fullname)
  3. SELECT users.name AS users_name,
  4. users.fullname AS users_fullname
  5. FROM users
  6. ()
  7. ed Ed Jones
  8. wendy Wendy Williams
  9. mary Mary Contrary
  10. fred Fred Flintstone

The tuples returned by Query are _named_tuples, supplied by the KeyedTuple class, and can be treated much like anordinary Python object. The names arethe same as the attribute’s name for an attribute, and the class name for aclass:

  1. sql>>> for row in session.query(User, User.name).all():
  2. ... print(row.User, row.name)
  3. SELECT users.id AS users_id,
  4. users.name AS users_name,
  5. users.fullname AS users_fullname,
  6. users.nickname AS users_nickname
  7. FROM users
  8. ()
  9. <User(name='ed', fullname='Ed Jones', nickname='eddie')> ed
  10. <User(name='wendy', fullname='Wendy Williams', nickname='windy')> wendy
  11. <User(name='mary', fullname='Mary Contrary', nickname='mary')> mary
  12. <User(name='fred', fullname='Fred Flintstone', nickname='freddy')> fred

You can control the names of individual column expressions using thelabel() construct, which is available fromany ColumnElement-derived object, as well as any class attribute whichis mapped to one (such as User.name):

  1. sql>>> for row in session.query(User.name.label('name_label')).all():
  2. ... print(row.name_label)
  3. SELECT users.name AS name_label
  4. FROM users
  5. ()
    ed
  6. wendy
  7. mary
  8. fred

The name given to a full entity such as User, assuming that multipleentities are present in the call to query(), can be controlled usingaliased() :

  1. >>> from sqlalchemy.orm import aliased
  2. >>> user_alias = aliased(User, name='user_alias')
  3.  
  4. sql>>> for row in session.query(user_alias, user_alias.name).all():
  5. ... print(row.user_alias)
  6. SELECT user_alias.id AS user_alias_id,
  7. user_alias.name AS user_alias_name,
  8. user_alias.fullname AS user_alias_fullname,
  9. user_alias.nickname AS user_alias_nickname
  10. FROM users AS user_alias
  11. ()
    <User(name='ed', fullname='Ed Jones', nickname='eddie')>
  12. <User(name='wendy', fullname='Wendy Williams', nickname='windy')>
  13. <User(name='mary', fullname='Mary Contrary', nickname='mary')>
  14. <User(name='fred', fullname='Fred Flintstone', nickname='freddy')>

Basic operations with Query include issuingLIMIT and OFFSET, most conveniently using Python array slices and typically inconjunction with ORDER BY:

  1. sql>>> for u in session.query(User).order_by(User.id)[1:3]:
  2. ... print(u)
  3. SELECT users.id AS users_id,
  4. users.name AS users_name,
  5. users.fullname AS users_fullname,
  6. users.nickname AS users_nickname
  7. FROM users ORDER BY users.id
  8. LIMIT ? OFFSET ?
  9. (2, 1)
    <User(name='wendy', fullname='Wendy Williams', nickname='windy')>
  10. <User(name='mary', fullname='Mary Contrary', nickname='mary')>

and filtering results, which is accomplished either withfilter_by(), which uses keyword arguments:

  1. sql>>> for name, in session.query(User.name).\
  2. ... filter_by(fullname='Ed Jones'):
  3. ... print(name)
  4. SELECT users.name AS users_name FROM users
  5. WHERE users.fullname = ?
  6. ('Ed Jones',)
  7. ed

…or filter(), which uses more flexible SQLexpression language constructs. These allow you to use regular Pythonoperators with the class-level attributes on your mapped class:

  1. sql>>> for name, in session.query(User.name).\
  2. ... filter(User.fullname=='Ed Jones'):
  3. ... print(name)
  4. SELECT users.name AS users_name FROM users
  5. WHERE users.fullname = ?
  6. ('Ed Jones',)
  7. ed

The Query object is fully generative, meaningthat most method calls return a new Queryobject upon which further criteria may be added. For example, to query forusers named “ed” with a full name of “Ed Jones”, you can callfilter() twice, which joins criteria usingAND:

  1. sql>>> for user in session.query(User).\
  2. ... filter(User.name=='ed').\
  3. ... filter(User.fullname=='Ed Jones'):
  4. ... print(user)
  5. SELECT users.id AS users_id,
  6. users.name AS users_name,
  7. users.fullname AS users_fullname,
  8. users.nickname AS users_nickname
  9. FROM users
  10. WHERE users.name = ? AND users.fullname = ?
  11. ('ed', 'Ed Jones')
  12. <User(name='ed', fullname='Ed Jones', nickname='eddie')>

Common Filter Operators

Here’s a rundown of some of the most common operators used infilter():

  1. query.filter(User.name == 'ed')
  1. query.filter(User.name != 'ed')
  1. query.filter(User.name.like('%ed%'))

Note

ColumnOperators.like() renders the LIKE operator, whichis case insensitive on some backends, and case sensitiveon others. For guaranteed case-insensitive comparisons, useColumnOperators.ilike().

  • ILIKE (case-insensitive LIKE):
  1. query.filter(User.name.ilike('%ed%'))

Note

most backends don’t support ILIKE directly. For those,the ColumnOperators.ilike() operator renders an expressioncombining LIKE with the LOWER SQL function applied to each operand.

  1. query.filter(User.name.in_(['ed', 'wendy', 'jack']))
  2.  
  3. # works with query objects too:
  4. query.filter(User.name.in_(
  5. session.query(User.name).filter(User.name.like('%ed%'))
  6. ))
  7.  
  8. # use tuple_() for composite (multi-column) queries
  9. from sqlalchemy import tuple_
  10. query.filter(
  11. tuple_(User.name, User.nickname).\
  12. in_([('ed', 'edsnickname'), ('wendy', 'windy')])
  13. )
  1. query.filter(~User.name.in_(['ed', 'wendy', 'jack']))
  1. query.filter(User.name == None)
  2.  
  3. # alternatively, if pep8/linters are a concern
  4. query.filter(User.name.is_(None))
  1. query.filter(User.name != None)
  2.  
  3. # alternatively, if pep8/linters are a concern
  4. query.filter(User.name.isnot(None))
  1. # use and_()
  2. from sqlalchemy import and_
  3. query.filter(and_(User.name == 'ed', User.fullname == 'Ed Jones'))
  4.  
  5. # or send multiple expressions to .filter()
  6. query.filter(User.name == 'ed', User.fullname == 'Ed Jones')
  7.  
  8. # or chain multiple filter()/filter_by() calls
  9. query.filter(User.name == 'ed').filter(User.fullname == 'Ed Jones')

Note

Make sure you use and_() and not thePython and operator!

  1. from sqlalchemy import or_
  2. query.filter(or_(User.name == 'ed', User.name == 'wendy'))

Note

Make sure you use or_() and not thePython or operator!

  1. query.filter(User.name.match('wendy'))

Note

match() uses a database-specific MATCHor CONTAINS function; its behavior will vary by backend and is notavailable on some backends such as SQLite.

Returning Lists and Scalars

A number of methods on Queryimmediately issue SQL and return a value containing loadeddatabase results. Here’s a brief tour:

  1. >>> query = session.query(User).filter(User.name.like('%ed')).order_by(User.id)
  2. sql>>> query.all()
  3. SELECT users.id AS users_id,
  4. users.name AS users_name,
  5. users.fullname AS users_fullname,
  6. users.nickname AS users_nickname
  7. FROM users
  8. WHERE users.name LIKE ? ORDER BY users.id
  9. ('%ed',)
  10. [<User(name='ed', fullname='Ed Jones', nickname='eddie')>,
  11. <User(name='fred', fullname='Fred Flintstone', nickname='freddy')>]

Warning

When the Query object returns lists of ORM-mapped objectssuch as the User object above, the entries are deduplicatedbased on primary key, as the results are interpreted from the SQLresult set. That is, if SQL query returns a row with id=7 twice,you would only get a single User(id=7) object back in the resultlist. This does not apply to the case when individual columns arequeried.

See also

My Query does not return the same number of objects as query.count() tells me - why?

  • first() applies a limit of one and returnsthe first result as a scalar:
  1. sql>>> query.first()
  2. SELECT users.id AS users_id,
  3. users.name AS users_name,
  4. users.fullname AS users_fullname,
  5. users.nickname AS users_nickname
  6. FROM users
  7. WHERE users.name LIKE ? ORDER BY users.id
  8. LIMIT ? OFFSET ?
  9. ('%ed', 1, 0)
  10. <User(name='ed', fullname='Ed Jones', nickname='eddie')>
  • one() fully fetches all rows, and if notexactly one object identity or composite row is present in the result, raisesan error. With multiple rows found:
  1. >>> user = query.one()
  2. Traceback (most recent call last):
  3. ...
  4. MultipleResultsFound: Multiple rows were found for one()

With no rows found:

  1. >>> user = query.filter(User.id == 99).one()
  2. Traceback (most recent call last):
  3. ...
  4. NoResultFound: No row was found for one()

The one() method is great for systems that expect to handle“no items found” versus “multiple items found” differently; such as a RESTfulweb service, which may want to raise a “404 not found” when no results are found,but raise an application error when multiple results are found.

  • one_or_none() is like one(), except that if noresults are found, it doesn’t raise an error; it just returns None. Likeone(), however, it does raise an error if multiple results arefound.

  • scalar() invokes the one() method, and uponsuccess returns the first column of the row:

  1. >>> query = session.query(User.id).filter(User.name == 'ed').\
  2. ... order_by(User.id)
  3. sql>>> query.scalar()
  4. SELECT users.id AS users_id
  5. FROM users
  6. WHERE users.name = ? ORDER BY users.id
  7. ('ed',)
  8. 1

Using Textual SQL

Literal strings can be used flexibly withQuery, by specifying their usewith the text() construct, which is acceptedby most applicable methods. For example,filter() andorder_by():

  1. >>> from sqlalchemy import text
  2. sql>>> for user in session.query(User).\
  3. ... filter(text("id<224")).\
  4. ... order_by(text("id")).all():
  5. ... print(user.name)
  6. SELECT users.id AS users_id,
  7. users.name AS users_name,
  8. users.fullname AS users_fullname,
  9. users.nickname AS users_nickname
  10. FROM users
  11. WHERE id<224 ORDER BY id
  12. ()
  13. ed
  14. wendy
  15. mary
  16. fred

Bind parameters can be specified with string-based SQL, using a colon. Tospecify the values, use the params()method:

  1. sql>>> session.query(User).filter(text("id<:value and name=:name")).\
  2. ... params(value=224, name='fred').order_by(User.id).one()
  3. SELECT users.id AS users_id,
  4. users.name AS users_name,
  5. users.fullname AS users_fullname,
  6. users.nickname AS users_nickname
  7. FROM users
  8. WHERE id<? and name=? ORDER BY users.id
  9. (224, 'fred')
  10. <User(name='fred', fullname='Fred Flintstone', nickname='freddy')>

To use an entirely string-based statement, a text() constructrepresenting a complete statement can be passed tofrom_statement(). Without additionalspecifiers, the columns in the string SQL are matched to the model columnsbased on name, such as below where we use just an asterisk to representloading all columns:

  1. sql>>> session.query(User).from_statement(
  2. ... text("SELECT * FROM users where name=:name")).\
  3. ... params(name='ed').all()
  4. SELECT * FROM users where name=?
  5. ('ed',)
  6. [<User(name='ed', fullname='Ed Jones', nickname='eddie')>]

Matching columns on name works for simple cases but can become unwieldy whendealing with complex statements that contain duplicate column names or whenusing anonymized ORM constructs that don’t easily match to specific names.Additionally, there is typing behavior present in our mapped columns thatwe might find necessary when handling result rows. For these cases,the text() construct allows us to link its textual SQLto Core or ORM-mapped column expressions positionally; we can achieve thisby passing column expressions as positional arguments to theTextClause.columns() method:

  1. >>> stmt = text("SELECT name, id, fullname, nickname "
  2. ... "FROM users where name=:name")
  3. >>> stmt = stmt.columns(User.name, User.id, User.fullname, User.nickname)
  4. sql>>> session.query(User).from_statement(stmt).params(name='ed').all()
  5. SELECT name, id, fullname, nickname FROM users where name=?
  6. ('ed',)
  7. [<User(name='ed', fullname='Ed Jones', nickname='eddie')>]

New in version 1.1: The TextClause.columns() method now accepts column expressionswhich will be matched positionally to a plain text SQL result set,eliminating the need for column names to match or even be unique in theSQL statement.

When selecting from a text() construct, the Querymay still specify what columns and entities are to be returned; instead ofquery(User) we can also ask for the columns individually, as inany other case:

  1. >>> stmt = text("SELECT name, id FROM users where name=:name")
  2. >>> stmt = stmt.columns(User.name, User.id)
  3. sql>>> session.query(User.id, User.name).\
  4. ... from_statement(stmt).params(name='ed').all()
  5. SELECT name, id FROM users where name=?
  6. ('ed',)
  7. [(1, u'ed')]

See also

Using Textual SQL - The text() construct explainedfrom the perspective of Core-only queries.

Counting

Query includes a convenience method forcounting called count():

  1. sql>>> session.query(User).filter(User.name.like('%ed')).count()
  2. SELECT count(*) AS count_1
  3. FROM (SELECT users.id AS users_id,
  4. users.name AS users_name,
  5. users.fullname AS users_fullname,
  6. users.nickname AS users_nickname
  7. FROM users
  8. WHERE users.name LIKE ?) AS anon_1
  9. ('%ed',)
  10. 2

Counting on count()

Query.count() used to be a very complicated methodwhen it would try to guess whether or not a subquery was neededaround theexisting query, and in some exotic cases it wouldn’t do the right thing.Now that it uses a simple subquery every time, it’s only two lines longand always returns the right answer. Use func.count() if aparticular statement absolutely cannot tolerate the subquery being present.

The count() method is used to determinehow many rows the SQL statement would return. Lookingat the generated SQL above, SQLAlchemy always places whatever it is we arequerying into a subquery, then counts the rows from that. In some casesthis can be reduced to a simpler SELECT count(*) FROM table, howevermodern versions of SQLAlchemy don’t try to guess when this is appropriate,as the exact SQL can be emitted using more explicit means.

For situations where the “thing to be counted” needsto be indicated specifically, we can specify the “count” functiondirectly using the expression func.count(), available from thefunc construct. Below weuse it to return the count of each distinct user name:

  1. >>> from sqlalchemy import func
  2. sql>>> session.query(func.count(User.name), User.name).group_by(User.name).all()
  3. SELECT count(users.name) AS count_1, users.name AS users_name
  4. FROM users GROUP BY users.name
  5. ()
  6. [(1, u'ed'), (1, u'fred'), (1, u'mary'), (1, u'wendy')]

To achieve our simple SELECT count(*) FROM table, we can apply it as:

  1. sql>>> session.query(func.count('*')).select_from(User).scalar()
  2. SELECT count(?) AS count_1
  3. FROM users
  4. ('*',)
  5. 4

The usage of select_from() can be removed if we express the count in termsof the User primary key directly:

  1. sql>>> session.query(func.count(User.id)).scalar()
  2. SELECT count(users.id) AS count_1
  3. FROM users
  4. ()
  5. 4

Building a Relationship

Let’s consider how a second table, related to User, can be mapped andqueried. Users in our systemcan store any number of email addresses associated with their username. Thisimplies a basic one to many association from the users to a newtable which stores email addresses, which we will call addresses. Usingdeclarative, we define this table along with its mapped class, Address:

  1. >>> from sqlalchemy import ForeignKey
  2. >>> from sqlalchemy.orm import relationship
  3.  
  4. >>> class Address(Base):
  5. ... __tablename__ = 'addresses'
  6. ... id = Column(Integer, primary_key=True)
  7. ... email_address = Column(String, nullable=False)
  8. ... user_id = Column(Integer, ForeignKey('users.id'))
  9. ...
  10. ... user = relationship("User", back_populates="addresses")
  11. ...
  12. ... def __repr__(self):
  13. ... return "<Address(email_address='%s')>" % self.email_address
  14.  
  15. >>> User.addresses = relationship(
  16. ... "Address", order_by=Address.id, back_populates="user")

The above class introduces the ForeignKey construct, which is adirective applied to Column that indicates that values in thiscolumn should be constrained to be values present in the named remotecolumn. This is a core feature of relational databases, and is the “glue” thattransforms an otherwise unconnected collection of tables to have richoverlapping relationships. The ForeignKey above expresses thatvalues in the addresses.user_id column should be constrained tothose values in the users.id column, i.e. its primary key.

A second directive, known as relationship(),tells the ORM that the Address class itself should be linkedto the User class, using the attribute Address.user.relationship() uses the foreign keyrelationships between the two tables to determine the nature ofthis linkage, determining that Address.user will be many to one.An additional relationship() directive is placed on theUser mapped class under the attribute User.addresses. In bothrelationship() directives, the parameterrelationship.back_populates is assigned to refer to thecomplementary attribute names; by doing so, each relationship()can make intelligent decision about the same relationship as expressedin reverse; on one side, Address.user refers to a User instance,and on the other side, User.addresses refers to a list ofAddress instances.

Note

The relationship.back_populates parameter is a newerversion of a very common SQLAlchemy feature calledrelationship.backref. The relationship.backrefparameter hasn’t gone anywhere and will always remain available!The relationship.back_populates is the same thing, excepta little more verbose and easier to manipulate. For an overviewof the entire topic, see the section Linking Relationships with Backref.

The reverse side of a many-to-one relationship is always one to many.A full catalog of available relationship() configurationsis at Basic Relationship Patterns.

The two complementing relationships Address.user and User.addressesare referred to as a bidirectional relationship, and is a keyfeature of the SQLAlchemy ORM. The section Linking Relationships with Backrefdiscusses the “backref” feature in detail.

Arguments to relationship() which concern the remote classcan be specified using strings, assuming the Declarative system is inuse. Once all mappings are complete, these strings are evaluatedas Python expressions in order to produce the actual argument, in theabove case the User class. The names which are allowed duringthis evaluation include, among other things, the names of all classeswhich have been created in terms of the declared base.

See the docstring for relationship() for more detail on argument style.

Did you know ?

  • a FOREIGN KEY constraint in most (though not all) relational databases canonly link to a primary key column, or a column that has a UNIQUE constraint.

  • a FOREIGN KEY constraint that refers to a multiple column primary key, and itselfhas multiple columns, is known as a “composite foreign key”. It can alsoreference a subset of those columns.

  • FOREIGN KEY columns can automatically update themselves, in response to a changein the referenced column or row. This is known as the CASCADE referential action,and is a built in function of the relational database.

  • FOREIGN KEY can refer to its own table. This is referred to as a “self-referential”foreign key.

  • Read more about foreign keys at Foreign Key - Wikipedia.

We’ll need to create the addresses table in the database, so we will issueanother CREATE from our metadata, which will skip over tables which havealready been created:

  1. sql>>> Base.metadata.create_all(engine)
  2. PRAGMA...
  3. CREATE TABLE addresses (
  4. id INTEGER NOT NULL,
  5. email_address VARCHAR NOT NULL,
  6. user_id INTEGER,
  7. PRIMARY KEY (id),
  8. FOREIGN KEY(user_id) REFERENCES users (id)
  9. )
  10. ()
  11. COMMIT

Now when we create a User, a blank addresses collection will bepresent. Various collection types, such as sets and dictionaries, are possiblehere (see Customizing Collection Access for details), but bydefault, the collection is a Python list.

  1. >>> jack = User(name='jack', fullname='Jack Bean', nickname='gjffdd')
  2. >>> jack.addresses
  3. []

We are free to add Address objects on our User object. In this case wejust assign a full list directly:

  1. >>> jack.addresses = [
  2. ... Address(email_address='jack@google.com'),
  3. ... Address(email_address='j25@yahoo.com')]

When using a bidirectional relationship, elements added in one directionautomatically become visible in the other direction. This behavior occursbased on attribute on-change events and is evaluated in Python, withoutusing any SQL:

  1. >>> jack.addresses[1]
  2. <Address(email_address='j25@yahoo.com')>
  3.  
  4. >>> jack.addresses[1].user
  5. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')>

Let’s add and commit Jack Bean to the database. jack as wellas the two Address members in the corresponding addressescollection are both added to the session at once, using a processknown as cascading:

  1. >>> session.add(jack)
  2. sql>>> session.commit()
  3. INSERT INTO users (name, fullname, nickname) VALUES (?, ?, ?)
  4. ('jack', 'Jack Bean', 'gjffdd')
  5. INSERT INTO addresses (email_address, user_id) VALUES (?, ?)
  6. ('jack@google.com', 5)
  7. INSERT INTO addresses (email_address, user_id) VALUES (?, ?)
  8. ('j25@yahoo.com', 5)
  9. COMMIT

Querying for Jack, we get just Jack back. No SQL is yet issued for Jack’s addresses:

  1. sql>>> jack = session.query(User).\
  2. ... filter_by(name='jack').one()
  3. BEGIN (implicit)
  4. SELECT users.id AS users_id,
  5. users.name AS users_name,
  6. users.fullname AS users_fullname,
  7. users.nickname AS users_nickname
  8. FROM users
  9. WHERE users.name = ?
  10. ('jack',)
  11. >>> jack
  12. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')>

Let’s look at the addresses collection. Watch the SQL:

  1. sql>>> jack.addresses
  2. SELECT addresses.id AS addresses_id,
  3. addresses.email_address AS
  4. addresses_email_address,
  5. addresses.user_id AS addresses_user_id
  6. FROM addresses
  7. WHERE ? = addresses.user_id ORDER BY addresses.id
  8. (5,)
  9. [<Address(email_address='jack@google.com')>, <Address(email_address='j25@yahoo.com')>]

When we accessed the addresses collection, SQL was suddenly issued. Thisis an example of a lazy loading relationship. The addresses collectionis now loaded and behaves just like an ordinary list. We’ll cover waysto optimize the loading of this collection in a bit.

Querying with Joins

Now that we have two tables, we can show some more features of Query,specifically how to create queries that deal with both tables at the same time.The Wikipedia page on SQL JOIN offers a good introduction tojoin techniques, several of which we’ll illustrate here.

To construct a simple implicit join between User and Address,we can use Query.filter() to equate their related columns together.Below we load the User and Address entities at once using this method:

  1. sql>>> for u, a in session.query(User, Address).\
  2. ... filter(User.id==Address.user_id).\
  3. ... filter(Address.email_address=='jack@google.com').\
  4. ... all():
  5. ... print(u)
  6. ... print(a)
  7. SELECT users.id AS users_id,
  8. users.name AS users_name,
  9. users.fullname AS users_fullname,
  10. users.nickname AS users_nickname,
  11. addresses.id AS addresses_id,
  12. addresses.email_address AS addresses_email_address,
  13. addresses.user_id AS addresses_user_id
  14. FROM users, addresses
  15. WHERE users.id = addresses.user_id
  16. AND addresses.email_address = ?
  17. ('jack@google.com',)
  18. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')>
  19. <Address(email_address='jack@google.com')>

The actual SQL JOIN syntax, on the other hand, is most easily achievedusing the Query.join() method:

  1. sql>>> session.query(User).join(Address).\
  2. ... filter(Address.email_address=='jack@google.com').\
  3. ... all()
  4. SELECT users.id AS users_id,
  5. users.name AS users_name,
  6. users.fullname AS users_fullname,
  7. users.nickname AS users_nickname
  8. FROM users JOIN addresses ON users.id = addresses.user_id
  9. WHERE addresses.email_address = ?
  10. ('jack@google.com',)
  11. [<User(name='jack', fullname='Jack Bean', nickname='gjffdd')>]

Query.join() knows how to join between Userand Address because there’s only one foreign key between them. If therewere no foreign keys, or several, Query.join()works better when one of the following forms are used:

  1. query.join(Address, User.id==Address.user_id) # explicit condition
  2. query.join(User.addresses) # specify relationship from left to right
  3. query.join(Address, User.addresses) # same, with explicit target
  4. query.join('addresses') # same, using a string

As you would expect, the same idea is used for “outer” joins, using theouterjoin() function:

  1. query.outerjoin(User.addresses) # LEFT OUTER JOIN

The reference documentation for join() contains detailed informationand examples of the calling styles accepted by this method; join()is an important method at the center of usage for any SQL-fluent application.

What does Query select from if there’s multiple entities?

The Query.join() method will typically join from the leftmostitem in the list of entities, when the ON clause is omitted, or if theON clause is a plain SQL expression. To control the first entity in the listof JOINs, use the Query.select_from() method:

  1. query = session.query(User, Address).select_from(Address).join(User)

Using Aliases

When querying across multiple tables, if the same table needs to be referencedmore than once, SQL typically requires that the table be aliased withanother name, so that it can be distinguished against other occurrences ofthat table. The Query supports this mostexplicitly using the aliased construct. Below we join to the Addressentity twice, to locate a user who has two distinct email addresses at thesame time:

  1. >>> from sqlalchemy.orm import aliased
  2. >>> adalias1 = aliased(Address)
  3. >>> adalias2 = aliased(Address)
  4. sql>>> for username, email1, email2 in \
  5. ... session.query(User.name, adalias1.email_address, adalias2.email_address).\
  6. ... join(adalias1, User.addresses).\
  7. ... join(adalias2, User.addresses).\
  8. ... filter(adalias1.email_address=='jack@google.com').\
  9. ... filter(adalias2.email_address=='j25@yahoo.com'):
  10. ... print(username, email1, email2)
  11. SELECT users.name AS users_name,
  12. addresses_1.email_address AS addresses_1_email_address,
  13. addresses_2.email_address AS addresses_2_email_address
  14. FROM users JOIN addresses AS addresses_1
  15. ON users.id = addresses_1.user_id
  16. JOIN addresses AS addresses_2
  17. ON users.id = addresses_2.user_id
  18. WHERE addresses_1.email_address = ?
  19. AND addresses_2.email_address = ?
  20. ('jack@google.com', 'j25@yahoo.com')
  21. jack jack@google.com j25@yahoo.com

Using Subqueries

The Query is suitable for generating statementswhich can be used as subqueries. Suppose we wanted to load User objectsalong with a count of how many Address records each user has. The best wayto generate SQL like this is to get the count of addresses grouped by userids, and JOIN to the parent. In this case we use a LEFT OUTER JOIN so that weget rows back for those users who don’t have any addresses, e.g.:

  1. SELECT users.*, adr_count.address_count FROM users LEFT OUTER JOIN
  2. (SELECT user_id, count(*) AS address_count
  3. FROM addresses GROUP BY user_id) AS adr_count
  4. ON users.id=adr_count.user_id

Using the Query, we build a statement like thisfrom the inside out. The statement accessor returns a SQL expressionrepresenting the statement generated by a particularQuery - this is an instance of a select()construct, which are described in SQL Expression Language Tutorial:

  1. >>> from sqlalchemy.sql import func
  2. >>> stmt = session.query(Address.user_id, func.count('*').\
  3. ... label('address_count')).\
  4. ... group_by(Address.user_id).subquery()

The func keyword generates SQL functions, and the subquery() method onQuery produces a SQL expression constructrepresenting a SELECT statement embedded within an alias (it’s actuallyshorthand for query.statement.alias()).

Once we have our statement, it behaves like aTable construct, such as the one we created forusers at the start of this tutorial. The columns on the statement areaccessible through an attribute called c:

  1. sql>>> for u, count in session.query(User, stmt.c.address_count).\
  2. ... outerjoin(stmt, User.id==stmt.c.user_id).order_by(User.id):
  3. ... print(u, count)
  4. SELECT users.id AS users_id,
  5. users.name AS users_name,
  6. users.fullname AS users_fullname,
  7. users.nickname AS users_nickname,
  8. anon_1.address_count AS anon_1_address_count
  9. FROM users LEFT OUTER JOIN
  10. (SELECT addresses.user_id AS user_id, count(?) AS address_count
  11. FROM addresses GROUP BY addresses.user_id) AS anon_1
  12. ON users.id = anon_1.user_id
  13. ORDER BY users.id
  14. ('*',)
  15. <User(name='ed', fullname='Ed Jones', nickname='eddie')> None
  16. <User(name='wendy', fullname='Wendy Williams', nickname='windy')> None
  17. <User(name='mary', fullname='Mary Contrary', nickname='mary')> None
  18. <User(name='fred', fullname='Fred Flintstone', nickname='freddy')> None
  19. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')> 2

Selecting Entities from Subqueries

Above, we just selected a result that included a column from a subquery. Whatif we wanted our subquery to map to an entity ? For this we use aliased()to associate an “alias” of a mapped class to a subquery:

  1. sql>>> stmt = session.query(Address).\
  2. ... filter(Address.email_address != 'j25@yahoo.com').\
  3. ... subquery()
  4. >>> adalias = aliased(Address, stmt)
  5. >>> for user, address in session.query(User, adalias).\
  6. ... join(adalias, User.addresses):
  7. ... print(user)
  8. ... print(address)
  9. SELECT users.id AS users_id,
  10. users.name AS users_name,
  11. users.fullname AS users_fullname,
  12. users.nickname AS users_nickname,
  13. anon_1.id AS anon_1_id,
  14. anon_1.email_address AS anon_1_email_address,
  15. anon_1.user_id AS anon_1_user_id
  16. FROM users JOIN
  17. (SELECT addresses.id AS id,
  18. addresses.email_address AS email_address,
  19. addresses.user_id AS user_id
  20. FROM addresses
  21. WHERE addresses.email_address != ?) AS anon_1
  22. ON users.id = anon_1.user_id
  23. ('j25@yahoo.com',)
  24. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')>
  25. <Address(email_address='jack@google.com')>

Using EXISTS

The EXISTS keyword in SQL is a boolean operator which returns True if thegiven expression contains any rows. It may be used in many scenarios in placeof joins, and is also useful for locating rows which do not have acorresponding row in a related table.

There is an explicit EXISTS construct, which looks like this:

  1. >>> from sqlalchemy.sql import exists
  2. >>> stmt = exists().where(Address.user_id==User.id)
  3. sql>>> for name, in session.query(User.name).filter(stmt):
  4. ... print(name)
  5. SELECT users.name AS users_name
  6. FROM users
  7. WHERE EXISTS (SELECT *
  8. FROM addresses
  9. WHERE addresses.user_id = users.id)
  10. ()
  11. jack

The Query features several operators which makeusage of EXISTS automatically. Above, the statement can be expressed along theUser.addresses relationship using any():

  1. sql>>> for name, in session.query(User.name).\
  2. ... filter(User.addresses.any()):
  3. ... print(name)
  4. SELECT users.name AS users_name
  5. FROM users
  6. WHERE EXISTS (SELECT 1
  7. FROM addresses
  8. WHERE users.id = addresses.user_id)
  9. ()
  10. jack

any() takes criterion as well, to limit the rows matched:

  1. sql>>> for name, in session.query(User.name).\
  2. ... filter(User.addresses.any(Address.email_address.like('%google%'))):
  3. ... print(name)
  4. SELECT users.name AS users_name
  5. FROM users
  6. WHERE EXISTS (SELECT 1
  7. FROM addresses
  8. WHERE users.id = addresses.user_id AND addresses.email_address LIKE ?)
  9. ('%google%',)
  10. jack

has() is the same operator asany() for many-to-one relationships(note the ~ operator here too, which means “NOT”):

  1. sql>>> session.query(Address).\
  2. ... filter(~Address.user.has(User.name=='jack')).all()
  3. SELECT addresses.id AS addresses_id,
  4. addresses.email_address AS addresses_email_address,
  5. addresses.user_id AS addresses_user_id
  6. FROM addresses
  7. WHERE NOT (EXISTS (SELECT 1
  8. FROM users
  9. WHERE users.id = addresses.user_id AND users.name = ?))
  10. ('jack',)
  11. []

Common Relationship Operators

Here’s all the operators which build on relationships - each oneis linked to its API documentation which includes full details on usageand behavior:

  • eq() (many-to-one “equals” comparison):
  1. query.filter(Address.user == someuser)
  • ne() (many-to-one “not equals” comparison):
  1. query.filter(Address.user != someuser)
  • IS NULL (many-to-one comparison, also uses eq()):
  1. query.filter(Address.user == None)
  1. query.filter(User.addresses.contains(someaddress))
  • any() (used for collections):
  1. query.filter(User.addresses.any(Address.email_address == 'bar'))
  2.  
  3. # also takes keyword arguments:
  4. query.filter(User.addresses.any(email_address='bar'))
  • has() (used for scalar references):
  1. query.filter(Address.user.has(name='ed'))
  1. session.query(Address).with_parent(someuser, 'addresses')

Eager Loading

Recall earlier that we illustrated a lazy loading operation, whenwe accessed the User.addresses collection of a User and SQLwas emitted. If you want to reduce the number of queries (dramatically, in many cases),we can apply an eager load to the query operation. SQLAlchemyoffers three types of eager loading, two of which are automatic, and a thirdwhich involves custom criterion. All three are usually invoked via functions knownas query options which give additional instructions to the Query on howwe would like various attributes to be loaded, via the Query.options() method.

Selectin Load

In this case we’d like to indicate that User.addresses should load eagerly.A good choice for loading a set of objects as well as their related collectionsis the orm.selectinload() option, which emits a second SELECT statementthat fully loads the collections associated with the results just loaded.The name “selectin” originates from the fact that the SELECT statementuses an IN clause in order to locate related rows for multiple objectsat once:

  1. >>> from sqlalchemy.orm import selectinload
  2. sql>>> jack = session.query(User).\
  3. ... options(selectinload(User.addresses)).\
  4. ... filter_by(name='jack').one()
  5. SELECT users.id AS users_id,
  6. users.name AS users_name,
  7. users.fullname AS users_fullname,
  8. users.nickname AS users_nickname
  9. FROM users
  10. WHERE users.name = ?
  11. ('jack',)
  12. SELECT addresses.user_id AS addresses_user_id,
  13. addresses.id AS addresses_id,
  14. addresses.email_address AS addresses_email_address
  15. FROM addresses
  16. WHERE addresses.user_id IN (?)
  17. ORDER BY addresses.user_id, addresses.id
  18. (5,)
  19. >>> jack
  20. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')>
  21.  
  22. >>> jack.addresses
  23. [<Address(email_address='jack@google.com')>, <Address(email_address='j25@yahoo.com')>]

Joined Load

The other automatic eager loading function is more well known and is calledorm.joinedload(). This style of loading emits a JOIN, by defaulta LEFT OUTER JOIN, so that the lead object as well as the related objector collection is loaded in one step. We illustrate loading the sameaddresses collection in this way - note that even though the User.addressescollection on jack is actually populated right now, the querywill emit the extra join regardless:

  1. >>> from sqlalchemy.orm import joinedload
  2.  
  3. sql>>> jack = session.query(User).\
  4. ... options(joinedload(User.addresses)).\
  5. ... filter_by(name='jack').one()
  6. SELECT users.id AS users_id,
  7. users.name AS users_name,
  8. users.fullname AS users_fullname,
  9. users.nickname AS users_nickname,
  10. addresses_1.id AS addresses_1_id,
  11. addresses_1.email_address AS addresses_1_email_address,
  12. addresses_1.user_id AS addresses_1_user_id
  13. FROM users
  14. LEFT OUTER JOIN addresses AS addresses_1 ON users.id = addresses_1.user_id
  15. WHERE users.name = ? ORDER BY addresses_1.id
  16. ('jack',)
  17. >>> jack
  18. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')>
  19.  
  20. >>> jack.addresses
  21. [<Address(email_address='jack@google.com')>, <Address(email_address='j25@yahoo.com')>]

Note that even though the OUTER JOIN resulted in two rows, we still only gotone instance of User back. This is because Query applies a “uniquing”strategy, based on object identity, to the returned entities. This is specificallyso that joined eager loading can be applied without affecting the query results.

While joinedload() has been around for a long time, selectinload()is a newer form of eager loading. selectinload() tends to be more appropriatefor loading related collections while joinedload() tends to be better suitedfor many-to-one relationships, due to the fact that only one row is loadedfor both the lead and the related object. Another form of loading,subqueryload(), also exists, which can be used in place ofselectinload() when making use of composite primary keys on certainbackends.

joinedload() is not a replacement for join()

The join created by joinedload() is anonymously aliased such thatit does not affect the query results. An Query.order_by()or Query.filter() call cannot reference these aliasedtables - so-called “user space” joins are constructed usingQuery.join(). The rationale for this is that joinedload() is onlyapplied in order to affect how related objects or collections are loadedas an optimizing detail - it can be added or removed with no impacton actual results. See the section The Zen of Joined Eager Loading fora detailed description of how this is used.

Explicit Join + Eagerload

A third style of eager loading is when we are constructing a JOIN explicitly inorder to locate the primary rows, and would like to additionally apply the extratable to a related object or collection on the primary object. This featureis supplied via the orm.contains_eager() function, and is mosttypically useful for pre-loading the many-to-one object on a query that needsto filter on that same object. Below we illustrate loading an Addressrow as well as the related User object, filtering on the User named“jack” and using orm.contains_eager() to apply the “user” columns to the Address.userattribute:

  1. >>> from sqlalchemy.orm import contains_eager
  2. sql>>> jacks_addresses = session.query(Address).\
  3. ... join(Address.user).\
  4. ... filter(User.name=='jack').\
  5. ... options(contains_eager(Address.user)).\
  6. ... all()
  7. SELECT users.id AS users_id,
  8. users.name AS users_name,
  9. users.fullname AS users_fullname,
  10. users.nickname AS users_nickname,
  11. addresses.id AS addresses_id,
  12. addresses.email_address AS addresses_email_address,
  13. addresses.user_id AS addresses_user_id
  14. FROM addresses JOIN users ON users.id = addresses.user_id
  15. WHERE users.name = ?
  16. ('jack',)
  17. >>> jacks_addresses
  18. [<Address(email_address='jack@google.com')>, <Address(email_address='j25@yahoo.com')>]
  19.  
  20. >>> jacks_addresses[0].user
  21. <User(name='jack', fullname='Jack Bean', nickname='gjffdd')>

For more information on eager loading, including how to configure various formsof loading by default, see the section Relationship Loading Techniques.

Deleting

Let’s try to delete jack and see how that goes. We’ll mark the object as deletedin the session, then we’ll issue a count query to see that no rows remain:

  1. >>> session.delete(jack)
  2. sql>>> session.query(User).filter_by(name='jack').count()
  3. UPDATE addresses SET user_id=? WHERE addresses.id = ?
  4. ((None, 1), (None, 2))
  5. DELETE FROM users WHERE users.id = ?
  6. (5,)
  7. SELECT count(*) AS count_1
  8. FROM (SELECT users.id AS users_id,
  9. users.name AS users_name,
  10. users.fullname AS users_fullname,
  11. users.nickname AS users_nickname
  12. FROM users
  13. WHERE users.name = ?) AS anon_1
  14. ('jack',)
  15. 0

So far, so good. How about Jack’s Address objects ?

  1. sql>>> session.query(Address).filter(
  2. ... Address.email_address.in_(['jack@google.com', 'j25@yahoo.com'])
  3. ... ).count()
  4. SELECT count(*) AS count_1
  5. FROM (SELECT addresses.id AS addresses_id,
  6. addresses.email_address AS addresses_email_address,
  7. addresses.user_id AS addresses_user_id
  8. FROM addresses
  9. WHERE addresses.email_address IN (?, ?)) AS anon_1
  10. ('jack@google.com', 'j25@yahoo.com')
  11. 2

Uh oh, they’re still there ! Analyzing the flush SQL, we can see that theuser_id column of each address was set to NULL, but the rows weren’tdeleted. SQLAlchemy doesn’t assume that deletes cascade, you have to tell itto do so.

Configuring delete/delete-orphan Cascade

We will configure cascade options on the User.addresses relationshipto change the behavior. While SQLAlchemy allows you to add new attributes andrelationships to mappings at any point in time, in this case the existingrelationship needs to be removed, so we need to tear down the mappingscompletely and start again - we’ll close the Session:

  1. >>> session.close()
  2. ROLLBACK

and use a new declarative_base():

  1. >>> Base = declarative_base()

Next we’ll declare the User class, adding in the addresses relationshipincluding the cascade configuration (we’ll leave the constructor out too):

  1. >>> class User(Base):
  2. ... __tablename__ = 'users'
  3. ...
  4. ... id = Column(Integer, primary_key=True)
  5. ... name = Column(String)
  6. ... fullname = Column(String)
  7. ... nickname = Column(String)
  8. ...
  9. ... addresses = relationship("Address", back_populates='user',
  10. ... cascade="all, delete, delete-orphan")
  11. ...
  12. ... def __repr__(self):
  13. ... return "<User(name='%s', fullname='%s', nickname='%s')>" % (
  14. ... self.name, self.fullname, self.nickname)

Then we recreate Address, noting that in this case we’ve createdthe Address.user relationship via the User class already:

  1. >>> class Address(Base):
  2. ... __tablename__ = 'addresses'
  3. ... id = Column(Integer, primary_key=True)
  4. ... email_address = Column(String, nullable=False)
  5. ... user_id = Column(Integer, ForeignKey('users.id'))
  6. ... user = relationship("User", back_populates="addresses")
  7. ...
  8. ... def __repr__(self):
  9. ... return "<Address(email_address='%s')>" % self.email_address

Now when we load the user jack (below using get(),which loads by primary key), removing an address from thecorresponding addresses collection will result in that Addressbeing deleted:

  1. # load Jack by primary key
  2. sql>>> jack = session.query(User).get(5)
  3. BEGIN (implicit)
  4. SELECT users.id AS users_id,
  5. users.name AS users_name,
  6. users.fullname AS users_fullname,
  7. users.nickname AS users_nickname
  8. FROM users
  9. WHERE users.id = ?
  10. (5,)
  11.  
  12. # remove one Address (lazy load fires off)
  13. sql>>> del jack.addresses[1]
  14. SELECT addresses.id AS addresses_id,
  15. addresses.email_address AS addresses_email_address,
  16. addresses.user_id AS addresses_user_id
  17. FROM addresses
  18. WHERE ? = addresses.user_id
  19. (5,)
  20.  
  21. # only one address remains
  22. sql>>> session.query(Address).filter(
  23. ... Address.email_address.in_(['jack@google.com', 'j25@yahoo.com'])
  24. ... ).count()
  25. DELETE FROM addresses WHERE addresses.id = ?
  26. (2,)
  27. SELECT count(*) AS count_1
  28. FROM (SELECT addresses.id AS addresses_id,
  29. addresses.email_address AS addresses_email_address,
  30. addresses.user_id AS addresses_user_id
  31. FROM addresses
  32. WHERE addresses.email_address IN (?, ?)) AS anon_1
  33. ('jack@google.com', 'j25@yahoo.com')
  34. 1

Deleting Jack will delete both Jack and the remaining Address associatedwith the user:

  1. >>> session.delete(jack)
  2.  
  3. sql>>> session.query(User).filter_by(name='jack').count()
  4. DELETE FROM addresses WHERE addresses.id = ?
  5. (1,)
  6. DELETE FROM users WHERE users.id = ?
  7. (5,)
  8. SELECT count(*) AS count_1
  9. FROM (SELECT users.id AS users_id,
  10. users.name AS users_name,
  11. users.fullname AS users_fullname,
  12. users.nickname AS users_nickname
  13. FROM users
  14. WHERE users.name = ?) AS anon_1
  15. ('jack',)
  16. 0
  17.  
  18. sql>>> session.query(Address).filter(
  19. ... Address.email_address.in_(['jack@google.com', 'j25@yahoo.com'])
  20. ... ).count()
  21. SELECT count(*) AS count_1
  22. FROM (SELECT addresses.id AS addresses_id,
  23. addresses.email_address AS addresses_email_address,
  24. addresses.user_id AS addresses_user_id
  25. FROM addresses
  26. WHERE addresses.email_address IN (?, ?)) AS anon_1
  27. ('jack@google.com', 'j25@yahoo.com')
  28. 0

More on Cascades

Further detail on configuration of cascades is at Cascades.The cascade functionality can also integrate smoothly withthe ON DELETE CASCADE functionality of the relational database.See Using Passive Deletes for details.

Building a Many To Many Relationship

We’re moving into the bonus round here, but lets show off a many-to-manyrelationship. We’ll sneak in some other features too, just to take a tour.We’ll make our application a blog application, where users can writeBlogPost items, which have Keyword items associated with them.

For a plain many-to-many, we need to create an un-mapped Table constructto serve as the association table. This looks like the following:

  1. >>> from sqlalchemy import Table, Text
  2. >>> # association table
  3. >>> post_keywords = Table('post_keywords', Base.metadata,
  4. ... Column('post_id', ForeignKey('posts.id'), primary_key=True),
  5. ... Column('keyword_id', ForeignKey('keywords.id'), primary_key=True)
  6. ... )

Above, we can see declaring a Table directly is a little differentthan declaring a mapped class. Table is a constructor function, soeach individual Column argument is separated by a comma. TheColumn object is also given its name explicitly, rather than it beingtaken from an assigned attribute name.

Next we define BlogPost and Keyword, using complementaryrelationship() constructs, each referring to the post_keywordstable as an association table:

  1. >>> class BlogPost(Base):
  2. ... __tablename__ = 'posts'
  3. ...
  4. ... id = Column(Integer, primary_key=True)
  5. ... user_id = Column(Integer, ForeignKey('users.id'))
  6. ... headline = Column(String(255), nullable=False)
  7. ... body = Column(Text)
  8. ...
  9. ... # many to many BlogPost<->Keyword
  10. ... keywords = relationship('Keyword',
  11. ... secondary=post_keywords,
  12. ... back_populates='posts')
  13. ...
  14. ... def __init__(self, headline, body, author):
  15. ... self.author = author
  16. ... self.headline = headline
  17. ... self.body = body
  18. ...
  19. ... def __repr__(self):
  20. ... return "BlogPost(%r, %r, %r)" % (self.headline, self.body, self.author)
  21.  
  22.  
  23. >>> class Keyword(Base):
  24. ... __tablename__ = 'keywords'
  25. ...
  26. ... id = Column(Integer, primary_key=True)
  27. ... keyword = Column(String(50), nullable=False, unique=True)
  28. ... posts = relationship('BlogPost',
  29. ... secondary=post_keywords,
  30. ... back_populates='keywords')
  31. ...
  32. ... def __init__(self, keyword):
  33. ... self.keyword = keyword

Note

The above class declarations illustrate explicit init() methods.Remember, when using Declarative, it’s optional!

Above, the many-to-many relationship is BlogPost.keywords. The definingfeature of a many-to-many relationship is the secondary keyword argumentwhich references a Table object representing theassociation table. This table only contains columns which reference the twosides of the relationship; if it has any other columns, such as its ownprimary key, or foreign keys to other tables, SQLAlchemy requires a differentusage pattern called the “association object”, described atAssociation Object.

We would also like our BlogPost class to have an author field. We willadd this as another bidirectional relationship, except one issue we’ll have isthat a single user might have lots of blog posts. When we accessUser.posts, we’d like to be able to filter results further so as not toload the entire collection. For this we use a setting accepted byrelationship() called lazy='dynamic', whichconfigures an alternate loader strategy on the attribute:

  1. >>> BlogPost.author = relationship(User, back_populates="posts")
  2. >>> User.posts = relationship(BlogPost, back_populates="author", lazy="dynamic")

Create new tables:

  1. sql>>> Base.metadata.create_all(engine)
  2. PRAGMA...
  3. CREATE TABLE keywords (
  4. id INTEGER NOT NULL,
  5. keyword VARCHAR(50) NOT NULL,
  6. PRIMARY KEY (id),
  7. UNIQUE (keyword)
  8. )
  9. ()
  10. COMMIT
  11. CREATE TABLE posts (
  12. id INTEGER NOT NULL,
  13. user_id INTEGER,
  14. headline VARCHAR(255) NOT NULL,
  15. body TEXT,
  16. PRIMARY KEY (id),
  17. FOREIGN KEY(user_id) REFERENCES users (id)
  18. )
  19. ()
  20. COMMIT
  21. CREATE TABLE post_keywords (
  22. post_id INTEGER NOT NULL,
  23. keyword_id INTEGER NOT NULL,
  24. PRIMARY KEY (post_id, keyword_id),
  25. FOREIGN KEY(post_id) REFERENCES posts (id),
  26. FOREIGN KEY(keyword_id) REFERENCES keywords (id)
  27. )
  28. ()
  29. COMMIT

Usage is not too different from what we’ve been doing. Let’s give Wendy some blog posts:

  1. sql>>> wendy = session.query(User).\
  2. ... filter_by(name='wendy').\
  3. ... one()
  4. SELECT users.id AS users_id,
  5. users.name AS users_name,
  6. users.fullname AS users_fullname,
  7. users.nickname AS users_nickname
  8. FROM users
  9. WHERE users.name = ?
  10. ('wendy',)
  11. >>> post = BlogPost("Wendy's Blog Post", "This is a test", wendy)
  12. >>> session.add(post)

We’re storing keywords uniquely in the database, but we know that we don’thave any yet, so we can just create them:

  1. >>> post.keywords.append(Keyword('wendy'))
  2. >>> post.keywords.append(Keyword('firstpost'))

We can now look up all blog posts with the keyword ‘firstpost’. We’ll use theany operator to locate “blog posts where any of its keywords has thekeyword string ‘firstpost’”:

  1. sql>>> session.query(BlogPost).\
  2. ... filter(BlogPost.keywords.any(keyword='firstpost')).\
  3. ... all()
  4. INSERT INTO keywords (keyword) VALUES (?)
  5. ('wendy',)
  6. INSERT INTO keywords (keyword) VALUES (?)
  7. ('firstpost',)
  8. INSERT INTO posts (user_id, headline, body) VALUES (?, ?, ?)
  9. (2, "Wendy's Blog Post", 'This is a test')
  10. INSERT INTO post_keywords (post_id, keyword_id) VALUES (?, ?)
  11. (...)
  12. SELECT posts.id AS posts_id,
  13. posts.user_id AS posts_user_id,
  14. posts.headline AS posts_headline,
  15. posts.body AS posts_body
  16. FROM posts
  17. WHERE EXISTS (SELECT 1
  18. FROM post_keywords, keywords
  19. WHERE posts.id = post_keywords.post_id
  20. AND keywords.id = post_keywords.keyword_id
  21. AND keywords.keyword = ?)
  22. ('firstpost',)
  23. [BlogPost("Wendy's Blog Post", 'This is a test', <User(name='wendy', fullname='Wendy Williams', nickname='windy')>)]

If we want to look up posts owned by the user wendy, we can tellthe query to narrow down to that User object as a parent:

  1. sql>>> session.query(BlogPost).\
  2. ... filter(BlogPost.author==wendy).\
  3. ... filter(BlogPost.keywords.any(keyword='firstpost')).\
  4. ... all()
  5. SELECT posts.id AS posts_id,
  6. posts.user_id AS posts_user_id,
  7. posts.headline AS posts_headline,
  8. posts.body AS posts_body
  9. FROM posts
  10. WHERE ? = posts.user_id AND (EXISTS (SELECT 1
  11. FROM post_keywords, keywords
  12. WHERE posts.id = post_keywords.post_id
  13. AND keywords.id = post_keywords.keyword_id
  14. AND keywords.keyword = ?))
  15. (2, 'firstpost')
  16. [BlogPost("Wendy's Blog Post", 'This is a test', <User(name='wendy', fullname='Wendy Williams', nickname='windy')>)]

Or we can use Wendy’s own posts relationship, which is a “dynamic”relationship, to query straight from there:

  1. sql>>> wendy.posts.\
  2. ... filter(BlogPost.keywords.any(keyword='firstpost')).\
  3. ... all()
  4. SELECT posts.id AS posts_id,
  5. posts.user_id AS posts_user_id,
  6. posts.headline AS posts_headline,
  7. posts.body AS posts_body
  8. FROM posts
  9. WHERE ? = posts.user_id AND (EXISTS (SELECT 1
  10. FROM post_keywords, keywords
  11. WHERE posts.id = post_keywords.post_id
  12. AND keywords.id = post_keywords.keyword_id
  13. AND keywords.keyword = ?))
  14. (2, 'firstpost')
  15. [BlogPost("Wendy's Blog Post", 'This is a test', <User(name='wendy', fullname='Wendy Williams', nickname='windy')>)]

Further Reference

Query Reference: Query API

Mapper Reference: Mapper Configuration

Relationship Reference: Relationship Configuration

Session Reference: Using the Session