SQLAlchemy 1.2.16 released, Python ORM framework
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.2.16 has been released, this release contains various fixes.
- engine Fixed a regression introduced in version 1.2 where a refactor of the
SQLAlchemyErrorbase exception class introduced an inappropriate coercion of a plain string message into Unicode under python 2k, which is not handled by the Python interpreter for characters outside of the platform’s encoding (typically ascii). The
SQLAlchemyErrorclass now passes a bytestring through under Py2K for
__str__()as is the behavior of exception objects in general under Py2K, does a safe coercion to unicode utf-8 with backslash fallback for
__unicode__(). For Py3K the message is typically unicode already, but if not is again safe-coerced with utf-8 with backslash fallback for the
- sql mysql Fixed issue where the DDL emitted for
DropTableComment, which will be used by an upcoming version of Alembic, was incorrect for the MySQL and Oracle databases.
- postgresql Fixed issue where a
postgresql.ENUMor a custom domain present in a remote schema would not be recognized within column reflection if the name of the enum/domain or the name of the schema required quoting. A new parsing scheme now fully parses out quoted or non-quoted tokens including support for SQL-escaped quotes.
- postgresql Fixed issue where multiple
postgresql.ENUMobjects referred to by the same
MetaDataobject would fail to be created if multiple objects had the same name under different schema names. The internal memoization the PostgreSQL dialect uses to track if it has created a particular
postgresql.ENUMin the database during a DDL creation sequence now takes schema name into account.
- sqlite Reflection of an index based on SQL expressions are now skipped with a warning, in the same way as that of the Postgresql dialect, where we currently do not support reflecting indexes that have SQL expressions within them. Previously, an index with columns of None were produced which would break tools like Alembic.
- Fixed issue in “expanding IN” feature where using the same bound parameter name more than once in a query would lead to a KeyError within the process of rewriting the parameters in the query.¶