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] [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 sqlalchemy/alembic#1293 for details.

[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] [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] [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] [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] [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] [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