SQLAlchemy is a Python SQL toolkit and a database object mapping framework. It includes a complete enterprise-class persistence model, specifically for efficient and high-performance database access.
SQL databases behave less like object collections the more size and performance start to matter; object collections behave less like tables and rows the more abstraction starts to matter. SQLAlchemy aims to accommodate both of these principles.
SQLAlchemy considers the database to be a relational algebra engine, not just a collection of tables. Rows can be selected from not only tables but also joins and other select statements; any of these units can be composed into a larger structure. SQLAlchemy’s expression language builds on this concept from its core.
SQLAlchemy is most famous for its object-relational mapper (ORM), an optional component that provides the data mapper pattern, where classes can be mapped to the database in open ended, multiple ways – allowing the object model and database schema to develop in a cleanly decoupled way from the beginning.
SQLAlchemy’s overall approach to these problems is entirely different from that of most other SQL / ORM tools, rooted in a so-called complimentarity- oriented approach; instead of hiding away SQL and object relational details behind a wall of automation, all processes are fully exposed within a series of composable, transparent tools. The library takes on the job of automating redundant tasks while the developer remains in control of how the database is organized and how SQL is constructed.
The main goal of SQLAlchemy is to change the way you think about databases and SQL!
SQLAlchemy 1.3.7 has been released, this release contains various fixes.
Fixed regression caused by new selectinload for many-to-one logic where a primaryjoin condition not based on real foreign keys would cause KeyError if a related object did not exist for a given key value on the parent object.
Fixed bug where using
Query.first()or a slice expression in conjunction with a query that has an expression based “offset” applied would raise TypeError, due to an “or” conditional against “offset” that did not expect it to be a SQL expression as opposed to an integer or None.
Fixed issue where
Indexobject which contained a mixture of functional expressions which were not resolvable to a particular column, in combination with string-based column names, would fail to initialize its internal state correctly leading to failures during DDL compilation.
Fixed bug where
TypeEngine.column_expression()method would not be applied to subsequent SELECT statements inside of a UNION or other
CompoundSelect, even though the SELECT statements are rendered at the topmost level of the statement. New logic now differentiates between rendering the column expression, which is needed for all SELECTs in the list, vs. gathering the returned data type for the result row, which is needed only for the first SELECT.
Fixed issue where internal cloning of SELECT constructs could lead to a key error if the copy of the SELECT changed its state such that its list of columns changed. This was observed to be occurring in some ORM scenarios which may be unique to 1.3 and above, so is partially a regression fix.