aiosql 13.0

Simple SQL in Python

SQL is code. Write it, version control it, comment it, and run it using files. Writing your SQL code in Python programs as strings doesn’t allow you to easily reuse them in SQL GUIs or CLI tools like psql. With aiosql you can organize your SQL statements in .sql files, load them into your python application as methods to call without losing the ability to use them as you would any other SQL file.

This project supports standard PEP 249 and asyncio based drivers for SQLite (sqlite3, aiosqlite, apsw), PostgreSQL (psycopg (3), psycopg2, pg8000, pygresql, asyncpg), MySQL (PyMySQL, mysqlclient, mysql-connector, asyncmy with this adapter), MariaDB (mariadb), DuckDB (duckdb) and MS SQL Server (pymssql), However, some detailed feature support may vary depending on the underlying driver and database engine actual capabilities.

Other SQL database drivers which support the pyformat or named PEP 249 paramstyles should work as well by just passing the driver as a parameter when building queries. Thus Oracle Database (oracledb) or Snowflake (snowflake.connector) should work out of the box… Please report with an issue if it actually works for you! Otherwise, extensions to support other database drivers can be written by you! See: Database Driver Adapters. Feel free to pull request!

This module is an implementation of Kris Jenkins’ yesql Clojure library to the Python ecosystem.

Badges

Usage

Install from pypi, for instance by running pip install aiosql.

Then write parametric SQL queries in a file and execute it from Python methods, eg this greetings.sql file:

-- name: get_all_greetings()
-- Get all the greetings in the database
select greeting_id, greeting
  from greetings
 order by 1;

-- name: get_user_by_username(username)^
-- Get a user from the database using a named parameter
select user_id, username, name
  from users
  where username = :username;

This example has an imaginary SQLite database with greetings and users. It prints greetings in various languages to the user and showcases the basic feature of being able to load queries from a SQL file and call them by name in python code. Query parameter declarations (eg (username)) are optional, and enforced when provided.

You can use aiosql to load the queries in this file for use in your Python application:

import aiosql
import sqlite3

queries = aiosql.from_path("greetings.sql", "sqlite3")

with sqlite3.connect("greetings.db") as conn:
    user = queries.get_user_by_username(conn, username="willvaughn")
    # user: (1, "willvaughn", "William")

    for _, greeting in queries.get_all_greetings(conn):
        # scan: (1, "Hi"), (2, "Aloha"), (3, "Hola"), …
        print(f"{greeting}, {user[2]}!")
    # Hi, William!
    # Aloha, William!
    # …

Or even in an asynchroneous way, with two SQL queries running in parallel using aiosqlite and asyncio:

import asyncio
import aiosql
import aiosqlite

queries = aiosql.from_path("greetings.sql", "aiosqlite")

async def main():
    # Parallel queries!!!
    async with aiosqlite.connect("greetings.db") as conn:
        greetings, user = await asyncio.gather(
            queries.get_all_greetings(conn),
            queries.get_user_by_username(conn, username="willvaughn")
        )

        for _, greeting in greetings:
            print(f"{greeting}, {user[2]}!")

asyncio.run(main())

It may seem inconvenient to provide a connection on each call. You may have a look at the AnoDB DB class which wraps both a database connection and queries in one connection-like extended object, including performing automatic reconnection when needed. The wrapper also allows to cache query results.

Why you might want to use this

• You think SQL is pretty good, and writing SQL is an important part of your applications.

• You don’t want to write your SQL in strings intermixed with your python code.

• You’re not using an ORM like SQLAlchemy or Django , with large (100k lines) code imprints vs under 900 for aiosql and under 300 for anodb, and you don’t need to or don’t want to write SQL-like code with a Python syntax.

• You want to be able to reuse your SQL in other contexts. Loading it into psql or other database tools.

Why you might NOT want to use this

• You’re looking for an ORM.

• You aren’t comfortable writing SQL code.

• You don’t have anything in your application that requires complicated SQL beyond basic CRUD operations.

• Dynamically loaded objects built at runtime really bother you.