CodeVetter · Repo Unpack · System map
sqlalchemy/sqlalchemy
The primary entrypoints are imported Python APIs rather than an application startup command. Core separates SQL construction and compilation from connection ownership and driver execution; the ORM adds mapping and session state above that boundary. Database drivers own external persistence, while SQLAlchemy owns pools, compiled statements, and mapped-object state in process. Packaging supports Python and optional Cython implementations, with Nox and GitHub Actions coordinating verification and wheel production.
- lib/sqlalchemy/__init__.py exposes create_engine, Engine, Connection, Result, URL, pools, schema objects, and SQL expression constructors as the public package facade.
- An Engine references a Dialect and Pool; ordinary construction defers the first DBAPI connection until connect(), begin(), or dependent Session work requires it.
- SQLCompiler, DDLCompiler, and GenericTypeCompiler render SQL, schema statements, and type specifications; executable expression objects enter the connection layer through _execute_on_connection.
- Mapper associates Python classes with relational structures, Session orchestrates flushes, and UOWTransaction owns dependency-ordered flush actions.
- Built-in dialect loading covers MSSQL, MySQL, Oracle, PostgreSQL, and SQLite, with a MariaDB loader branch; optional dependency groups select concrete synchronous and async drivers.
- The external storage boundary is the DBAPI: DefaultDialect.connect calls loaded_dbapi.connect, execution calls cursor methods, and commit calls the driver's connection.commit.
- The setuptools package requires Python >=3.11 and typing-extensions; CPython builds can compile eight Cython modules, controlled by DISABLE_SQLALCHEMY_CEXT and REQUIRE_SQLALCHEMY_CEXT.
- Verification uses pytest through Nox, while release-created GitHub workflows build compiled and pure-Python wheels with cibuildwheel or python -m build.