2.0.23

Released: November 2, 2023

orm

• [orm] [usecase] Implemented the _orm.Session.bulk_insert_mappings.render_nulls parameter for new style bulk ORM inserts, allowing render_nulls=True as an execution option. This allows for bulk ORM inserts with a mixture of None values in the parameter dictionaries to use a single batch of rows for a given set of dicationary keys, rather than breaking up into batches that omit the NULL columns from each INSERT.

  References: #10575

• [orm] [bug] Fixed issue where the __allow_unmapped__ directive failed to allow for legacy Column / deferred() mappings that nonetheless had annotations such as Any or a specific type without Mapped[] as their type, without errors related to locating the attribute name.

  References: #10516

• [orm] [bug] Fixed caching bug where using the _orm.with_expression() construct in conjunction with loader options _orm.selectinload(), _orm.lazyload() would fail to substitute bound parameter values correctly on subsequent caching runs.

  References: #10570

• [orm] [bug] Fixed bug in ORM annotated declarative where using a ClassVar that nonetheless referred in some way to an ORM mapped class name would fail to be interpreted as a ClassVar that's not mapped.

  References: #10472

sql

• [sql] [usecase] Implemented "literal value processing" for the Interval datatype for both the PostgreSQL and Oracle dialects, allowing literal rendering of interval values. Pull request courtesy Indivar Mishra.

  References: #9737

• [sql] [bug] Fixed issue where using the same bound parameter more than once with literal_execute=True in some combinations with other literal rendering parameters would cause the wrong values to render due to an iteration issue.

  This change is also backported to: 1.4.50

  References: #10142

• [sql] [bug] Added compiler-level None/NULL handling for the "literal processors" of all datatypes that include literal processing, that is, where a value is rendered inline within a SQL statement rather than as a bound parameter, for all those types that do not feature explicit "null value" handling. Previously this behavior was undefined and inconsistent.

  References: #10535

• [sql] Removed unused placeholder method TypeEngine.compare_against_backend() This method was used by very old versions of Alembic. See https://github.com/sqlalchemy/alembic/issues/1293 for details.

asyncio

• [asyncio] [bug] Fixed bug with method _asyncio.AsyncSession.close_all() that was not working correctly. Also added function _asyncio.close_all_sessions() that's the equivalent of _orm.close_all_sessions(). Pull request courtesy of Bryan不可思议.

  References: #10421

postgresql

• [postgresql] [bug] Fixed 2.0 regression caused by #7744 where chains of expressions involving PostgreSQL JSON operators combined with other operators such as string concatenation would lose correct parenthesization, due to an implementation detail specific to the PostgreSQL dialect.

  References: #10479

• [postgresql] [bug] Fixed SQL handling for "insertmanyvalues" when using the postgresql.BIT datatype with the asyncpg backend. The postgresql.BIT on asyncpg apparently requires the use of an asyncpg-specific BitString type which is currently exposed when using this DBAPI, making it incompatible with other PostgreSQL DBAPIs that all work with plain bitstrings here. A future fix in version 2.1 will normalize this datatype across all PG backends. Pull request courtesy Sören Oldag.

  References: #10532

mysql

• [mysql] [bug] Repaired a new incompatibility in the MySQL "pre-ping" routine where the False argument passed to connection.ping(), which is intended to disable an unwanted "automatic reconnect" feature, is being deprecated in MySQL drivers and backends, and is producing warnings for some versions of MySQL's native client drivers. It's removed for mysqlclient, whereas for PyMySQL and drivers based on PyMySQL, the parameter will be deprecated and removed at some point, so API introspection is used to future proof against these various stages of removal.

  This change is also backported to: 1.4.50

  References: #10492

mariadb

• [mariadb] [bug] Adjusted the MySQL / MariaDB dialects to default a generated column to NULL when using MariaDB, if _schema.Column.nullable was not specified with an explicit True or False value, as MariaDB does not support the "NOT NULL" phrase with a generated column. Pull request courtesy Indivar.

  References: #10056

• [mariadb] [bug] [regression] Established a workaround for what seems to be an intrinsic issue across MySQL/MariaDB drivers where a RETURNING result for DELETE DML which returns no rows using SQLAlchemy's "empty IN" criteria fails to provide a cursor.description, which then yields result that returns no rows, leading to regressions for the ORM that in the 2.0 series uses RETURNING for bulk DELETE statements for the "synchronize session" feature. To resolve, when the specific case of "no description when RETURNING was given" is detected, an "empty result" with a correct cursor description is generated and used in place of the non-working cursor.

  References: #10505

mssql

• [mssql] [usecase] Added support for the aioodbc driver implemented for SQL Server, which builds on top of the pyodbc and general aio* dialect architecture.

  References: #6521

• [mssql] [bug] [reflection] Fixed issue where identity column reflection would fail for a bigint column with a large identity start value (more than 18 digits).

  This change is also backported to: 1.4.50

  References: #10504

oracle

• [oracle] [bug] Fixed issue in Interval datatype where the Oracle implementation was not being used for DDL generation, leading to the day_precision and second_precision parameters to be ignored, despite being supported by this dialect. Pull request courtesy Indivar.

  References: #10509

• [oracle] [bug] Fixed issue where the cx_Oracle dialect claimed to support a lower cx_Oracle version (7.x) than was actually supported in practice within the 2.0 series of SQLAlchemy. The dialect imports symbols that are only in cx_Oracle 8 or higher, so runtime dialect checks as well as setup.cfg requirements have been updated to reflect this compatibility.

  References: #10470