This article is part 9 of 10 in the series Python SQLAlchemy Tutorial

Expression Language

One of the core components of SQLAlchemy is the Expression Language. It is allows the programmer to specify SQL statements in Python constructs and use the constructs directly in more complex queries. Since the expression language is backend-neutral and comprehensively covers every aspect of raw SQL, it is closer to raw SQL than any other component in SQLAlchemy. In this article, we are going to illustrate the power of the expression language using a three table database.

Database Models

Suppose we want to model multiple shopping carts, each of which is created by a user and stores multiple products. From the specification, we can deduce that a user owns multiple shopping carts, a shopping cart includes multiple products, and a product can be included in multiple shopping carts. Therefore, we want to establish a many-to-many relationship between ShoppingCart and Product, and another one-to-many between User and ShoppingCart. Let's create the database models:

Create Users, Products and Shopping Carts

Now let's create one user and several products.

Before progressing further, let's verify that we have one user and three products in the database now.

Now we can create two shopping carts for user John.

Use the Expression Language to Query the Database

Now we have one user, three products and two shopping carts in the database, we can start playing with the expression language. First, let's write a query to answer the question: which products' prices are higher than $100.00?

Then, let's write a query to answer a more complicated question: which shopping carts contain at least one product whose price is higher than $100.00?

Then, let's write a query to answer a slightly different question: which shopping carts contain no product whose price is lower than $100.00?

Or the previous question can be formed in a different way: how can we find the shopping carts all of whose products have a price higher than $100.00?

Now, we can ask a different kind of questions regarding aggregation over Product.price. For example, we can ask: which shopping carts' total price of the products is higher than $200.00?

In the previous example, we begin with constructing an SQLAlchemy selectable total_price_of_shopping_carts whose 'columns' are ShoppingCart.id of each shopping cart and the sum of all the products' prices in each corresponding shopping cart. Once we have such a selectable, it's easy to write the query that finds all the shopping carts whose sum of products' prices are higher than $200.00.

Potential Gotchas

So far, our example program seems to be working pretty well. But if we accidentally break the program by writing and using the constructs in unintended ways? Will SQLAlchemy inform us about what's wrong with our program so we can debug it?

For example, the column Product.price is defined as a Float. What if we create a Product object with a price that's a string? Will SQLAlchemy break because the data type of the input for price is different from the definition? Let's give it a try.

So, the product CPU with a string price was inserted successfully into the database. How about using a string for the price that is not a number at all?

Oops. Now SQLAlchemy raises a StatementError because "asdf" cannot be converted into a Float. This is a good feature since it eliminates potential programming errors caused by carelessness.

You might also notice that the filter() method in our example use expressions such as Product.name == 'CPU' and Product.price > 100.0. Aren't these expressions being evaluated first and then the resulting Boolean values are passed into the filter() function to get actual filter results? Let's use several examples to verify the behaviour of filter().

From the examples above, we see that filter() does accept straightforward Boolean values like True, which returns all products in the database. However, it does not accept expression like Product.name = 'CPU' whose meaning is unclear in the context of a filter. Like the Product constructor, it also converts a String value '100.0' into a float and filter the product table based on the final criteria.

Now let's examine several cases where the SQLAlchemy API might look a bit less than intuitive. First, the select() statement seems to only accept a list of columns as the first argument like select([Product.id]). Wouldn't it be nice if we can write something like select(Product.id)?

Oops. SQLAlchemy does not like a single element as the first argument of select(). Remember, always pass in a list.

Second, the syntax in some of the where clauses do not look Pythonic: ShoppingCart.products.any(Product.id.in_(product_higher_than_one_hundred)). Wouldn't it be nice if we can write something like ShoppingCart.products.any(Product.id in product_higher_than_one_hundred))?

Since SQLAlchemy's 'Select' objects are not iterable, using it in a in context does not work. It may look like a downside, but it makes sense since a 'Select' object is very flexible in SQLAlchemy. As what's shown in the examples, a 'Select' object can be passed around into any filter() or where() to become part of a more complex query or event another 'Select' object. Supporting iterable on such an object would require lots of changes to the underlying implementation.

Third, the results of query() seem to be returning objects that are formatted nicely, such as ( :u'CPU':300.0 ) as the display for one Product object. It looks different from a typical object like:

Why? It's because we overrode the __repr__() method of Product and the print() command from the Python interpreter is calling repr() on the resulting array of Product and ShoppingCart objects which call __repr__() of each corresponding class's implementation.

Finally, why does SQLAlchemy implement their own Float column type? Why can't they re-use Python's internal float type?

Well, the short answer is that SQLAlchemy is an ORM and an ORM maps Python constructs into SQL constructs using a defined type system, and the type system has to be database-agnostic, which means it has to handle different database backends with the same column type. And the long answer is that every column defined in a model has to be defined by SQLAlchemy and the definition / column type implements custom methods that are called by the SQLAlchemy's lower level API to convert a Python construct into a corresponding SQL construct.

Tips and Summary

In this article, we used a three-table database to illustrate how to use SQLAlchemy's Expression Language. One thing to keep in mind is that we use mathematical sets to guide us on writing SQL queries. Whenever we encounter a question that's not trivial, especially a question involving multiple tables, we should divide and conquer the question by answering parts of the question first. For example, the question 'how can we find all the shopping carts whose products' sum of prices are higher than $200.00' can be divided into the following ones: 1. how can we calculate the sum of products' prices? (func.sum()) 2. how can we list all the tuples (ShoppingCart.id, func.sum(Product.price)) in a selectable? 3. how can we use the selectable to write the actual query?

About The Author