Сегодня я для себя открыл: Pony ORM — элегантная работа с базами данных в Python

Введение

Каждый разработчик, работающий с Python, рано или поздно сталкивается с необходимостью взаимодействия с реляционными базами данных. Традиционные подходы — написание сырых SQL-запросов или использование ORM вроде SQLAlchemy — имеют свои плюсы и минусы. Но недавно на Habr появилась статья, которая заставила многих (и меня в том числе) пересмотреть свои взгляды на ORM. Речь идёт о Pony ORM — легковесной, интуитивно понятной библиотеке, которая предлагает уникальный синтаксис для работы с данными.

Автор материала делится личным опытом перехода с SQLAlchemy на Pony ORM в небольшом проекте по учёту финансов. Он отмечает, что Pony ORM, хоть и не так популярна, как SQLAlchemy, заслуживает внимания благодаря своей простоте и выразительности. В этой статье мы разберём, что такое Pony ORM, как она работает, и почему она может стать вашим новым фаворитом. Источник

Pony ORM была создана в 2010 году как open-source проект. Её главная особенность — использование генераторов (generators) для определения запросов, что делает код читаемым и лаконичным. В отличие от SQLAlchemy, где запросы строятся через цепочки методов, Pony ORM позволяет писать запросы почти как на чистом Python. Это существенно снижает порог входа для новичков и ускоряет разработку.

Что такое Pony ORM и чем она отличается от других ORM

Pony ORM — это библиотека для Python, которая предоставляет объектно-реляционное отображение (ORM) для работы с базами данных: SQLite, PostgreSQL, MySQL, Oracle и другими. Её ключевое отличие — использование генераторов для создания запросов. Вместо того чтобы писать session.query(User).filter(User.name == 'Alice').all(), вы пишете:

for user in User.select(lambda u: u.name == 'Alice'):
    print(user.email)

Это выглядит как обычный цикл Python, но на самом деле Pony ORM транслирует его в оптимизированный SQL-запрос. Такой подход называется «генераторные запросы» (generator queries). Он позволяет избежать типичных ошибок, связанных с неправильным построением цепочек методов, и делает код более декларативным.

Для сравнения, вот таблица основных отличий Pony ORM от SQLAlchemy:

Как видно из таблицы, Pony ORM выигрывает в простоте и скорости для типовых задач, но уступает в гибкости при работе со сложными запросами. В статье на Habr автор подчёркивает, что для проектов малого и среднего размера Pony ORM — идеальный выбор, так как она позволяет быстро прототипировать и поддерживать код.

Как работает Pony ORM: установка и первый проект

Установка Pony ORM тривиальна. Достаточно выполнить:

pip install pony

После этого вы можете определить модель данных. Допустим, мы создаём приложение для учёта задач. Вот как это выглядит:

from pony.orm import *

db = Database()

class Task(db.Entity):
    id = PrimaryKey(int, auto=True)
    title = Required(str)
    description = Optional(str)
    status = Required(str, default='pending')
    created_at = Required(datetime, default=datetime.now)

db.bind(provider='sqlite', filename='tasks.sqlite', create_db=True)
db.generate_mapping(create_tables=True)

Теперь мы можем выполнять операции. Создание новой записи:

with db_session:
    Task(title='Купить продукты', description='Молоко, хлеб, яйца')
    commit()

Запрос всех задач со статусом 'pending':

with db_session:
    for task in Task.select(lambda t: t.status == 'pending'):
        print(f'{task.title}: {task.description}')

Обратите внимание на db_session. Это контекстный менеджер, который управляет транзакциями. Выход из блока автоматически коммитит или откатывает изменения. Это удобно и безопасно.

Практический пример: миграция с SQLAlchemy на Pony ORM

Автор статьи на Habr описывает свой проект — личный финансовый трекер. Изначально он использовал SQLAlchemy, но столкнулся с проблемами: объёмный код для простых запросов, сложность отладки и медленная загрузка данных при большом количестве связей. Решив попробовать Pony ORM, он переписал модель за несколько часов.

Вот как выглядела модель на SQLAlchemy:

from sqlalchemy import create_engine, Column, Integer, String, Float, ForeignKey, DateTime
from sqlalchemy.orm import declarative_base, relationship, Session

Base = declarative_base()

class Category(Base):
    __tablename__ = 'categories'
    id = Column(Integer, primary_key=True)
    name = Column(String, nullable=False)
    transactions = relationship('Transaction', back_populates='category')

class Transaction(Base):
    __tablename__ = 'transactions'
    id = Column(Integer, primary_key=True)
    amount = Column(Float, nullable=False)
    description = Column(String)
    category_id = Column(Integer, ForeignKey('categories.id'))
    category = relationship('Category', back_populates='transactions')
    created_at = Column(DateTime, default=datetime.now)

И тот же пример на Pony ORM:

from pony.orm import *

db = Database()

class Category(db.Entity):
    id = PrimaryKey(int, auto=True)
    name = Required(str)
    transactions = Set('Transaction')

class Transaction(db.Entity):
    id = PrimaryKey(int, auto=True)
    amount = Required(float)
    description = Optional(str)
    category = Required(Category)
    created_at = Required(datetime, default=datetime.now)

db.bind(provider='postgres', user='...', password='...', host='localhost', database='finance')
db.generate_mapping(create_tables=True)

Как видите, код стал короче и читаемее. Особенно впечатляет, что для определения связей не нужно писать ForeignKey вручную — Pony ORM делает это автоматически. Связь «один ко многим» выражается через Set('Transaction') и Required(Category). Это интуитивно понятно.

Поддержка сложных запросов и агрегаций

Pony ORM не ограничивается простыми запросами. Она поддерживает фильтрацию, сортировку, группировку и подзапросы. Например, чтобы получить сумму всех транзакций по каждой категории, можно написать:

with db_session:
    result = select((c.name, sum(t.amount)) for c in Category for t in c.transactions)
    for name, total in result:
        print(f'{name}: {total}')

Этот запрос эквивалентен SQL:

SELECT c.name, SUM(t.amount)
FROM categories c
JOIN transactions t ON t.category_id = c.id
GROUP BY c.name

Pony ORM автоматически генерирует эффективный SQL. Важно отметить, что библиотека использует ленивую загрузку (lazy loading) по умолчанию, но поддерживает и жадную загрузку (eager loading) через метод .prefetch(). Это позволяет избежать проблемы N+1 запросов.

Производительность и кэширование

Один из ключевых моментов, который обсуждается в статье, — производительность Pony ORM. Тесты показывают, что для простых CRUD-операций Pony ORM работает на 10-15% быстрее, чем SQLAlchemy, благодаря оптимизированному генератору запросов и встроенному кэшированию. Pony ORM кэширует результаты запросов в рамках одной сессии, что ускоряет повторные обращения.

Однако для сложных запросов с множественными JOIN и подзапросами SQLAlchemy может быть быстрее из-за более развитого оптимизатора. Автор статьи рекомендует использовать Pony ORM для проектов, где преобладают простые запросы, а SQLAlchemy — для систем с высокой нагрузкой и сложной бизнес-логикой.

Интеграция с веб-фреймворками

Pony ORM хорошо интегрируется с популярными веб-фреймворками: Flask, Django (через отдельный пакет), FastAPI и другими. Для Flask достаточно создать экземпляр Database и использовать декоратор @db_session() в обработчиках запросов. Например:

from flask import Flask
from pony.orm import *

app = Flask(__name__)
db = Database()

class User(db.Entity):
    id = PrimaryKey(int, auto=True)
    name = Required(str)
    email = Required(str, unique=True)

db.bind(provider='sqlite', filename='users.sqlite', create_db=True)
db.generate_mapping(create_tables=True)

@app.route('/users')
@db_session()
def list_users():
    users = select(u for u in User)[:]
    return {'users': [{'name': u.name, 'email': u.email} for u in users]}

Для FastAPI нужно использовать асинхронные сессии, но Pony ORM поддерживает асинхронность через db_session с async-генераторами. Это делает её пригодной для современных веб-приложений.

Недостатки и ограничения

Несмотря на все плюсы, у Pony ORM есть и недостатки. Во-первых, сообщество небольшое, поэтому найти готовые решения для нестандартных задач бывает сложно. Во-вторых, документация местами устарела и не покрывает все сценарии. В-третьих, Pony ORM не поддерживает асинхронные драйверы для PostgreSQL и MySQL напрямую, хотя есть обходные пути.

Также стоит отметить, что Pony ORM не подходит для проектов с очень высокой нагрузкой, где требуется тонкая настройка SQL. В таких случаях лучше использовать SQLAlchemy или даже сырые запросы.

Заключение

Pony ORM — это достойная альтернатива SQLAlchemy, особенно если вы цените простоту и элегантность кода. Она идеально подходит для прототипирования, небольших проектов и микросервисов. Генераторные запросы делают код интуитивным, а встроенное кэширование повышает производительность. Если вы ещё не знакомы с Pony ORM, рекомендую попробовать её в следующем проекте — возможно, она станет вашим новым открытием, как и для автора статьи на Habr.

Для тех, кто хочет углубиться в тему, есть официальная документация и репозиторий на GitHub. А если вы ищете готовые решения для автоматизации работы с данными, обратите внимание на платформы, которые поддерживают интеграцию с различными ORM и API. Например, ASI Biont поддерживает подключение к SQLite и PostgreSQL через API — подробнее на asibiont.com/courses.

В любом случае, выбор инструмента зависит от ваших задач. Pony ORM заслуживает места в арсенале Python-разработчика, и я надеюсь, что эта статья помогла вам лучше понять её возможности.