I built this because I hit a frustration point with the FastAPI ecosystem: the fragmentation between async code (API routes) and sync code (Celery workers / CLI scripts).
I found myself writing the same query logic twice, once with `await session.execute(...)` and once with blocking calls or dealing with complex `asgiref` wrappers just to reuse model logic in background tasks.
DuoORM is an opinionated Active Record layer over SQLAlchemy 2.0 that enforces "Symmetry." The goal is that `User.where(...)` works identically in both contexts, with the library handling the event loop detection and session management under the hood.
It handles the Pydantic V2 translation and Alembic scaffolding automatically.
The Trade-off: It effectively hides the `Session` object from you for simple CRUD. This is great for velocity but might annoy purists who want explicit Unit of Work control everywhere. Though you can an dedicated "transaction" block for greater control. Also, I added an `.alchemize()` escape hatch to drop down to raw SQLAlchemy constructs when needed.
Happy to answer questions on the implementation details or the decision to abstract the session.
Author here.
I built this because I hit a frustration point with the FastAPI ecosystem: the fragmentation between async code (API routes) and sync code (Celery workers / CLI scripts).
I found myself writing the same query logic twice, once with `await session.execute(...)` and once with blocking calls or dealing with complex `asgiref` wrappers just to reuse model logic in background tasks.
DuoORM is an opinionated Active Record layer over SQLAlchemy 2.0 that enforces "Symmetry." The goal is that `User.where(...)` works identically in both contexts, with the library handling the event loop detection and session management under the hood.
It handles the Pydantic V2 translation and Alembic scaffolding automatically.
The Trade-off: It effectively hides the `Session` object from you for simple CRUD. This is great for velocity but might annoy purists who want explicit Unit of Work control everywhere. Though you can an dedicated "transaction" block for greater control. Also, I added an `.alchemize()` escape hatch to drop down to raw SQLAlchemy constructs when needed.
Happy to answer questions on the implementation details or the decision to abstract the session.