2.0.26

Released: February 11, 2024

orm

• [orm] [bug] Replaced the "loader depth is excessively deep" warning with a shorter
  message added to the caching badge within SQL logging, for those statements
  where the ORM disabled the cache due to a too-deep chain of loader options.
  The condition which this warning highlights is difficult to resolve and is
  generally just a limitation in the ORM's application of SQL caching. A
  future feature may include the ability to tune the threshold where caching
  is disabled, but for now the warning will no longer be a nuisance.

  References: #10896

• [orm] [bug] Fixed issue where it was not possible to use a type (such as an enum)
  within a _orm.Mapped container type if that type were declared
  locally within the class body. The scope of locals used for the eval now
  includes that of the class body itself. In addition, the expression within
  _orm.Mapped may also refer to the class name itself, if used as a
  string or with future annotations mode.

  References: #10899

• [orm] [bug] Fixed issue where using _orm.Session.delete() along with the
  _orm.Mapper.version_id_col feature would fail to use the
  correct version identifier in the case that an additional UPDATE were
  emitted against the target object as a result of the use of
  _orm.relationship.post_update on the object. The issue is
  similar to #10800 just fixed in version 2.0.25 for the case of
  updates alone.

  References: #10967

• [orm] [bug] Fixed issue where an assertion within the implementation for
  _orm.with_expression() would raise if a SQL expression that was not
  cacheable were used; this was a 2.0 regression since 1.4.

  References: #10990

examples

• [examples] [bug] Fixed regression in history_meta example where the use of
  _schema.MetaData.to_metadata() to make a copy of the history table
  would also copy indexes (which is a good thing), but causing naming
  conflicts indexes regardless of naming scheme used for those indexes. A
  "_history" suffix is now added to these indexes in the same way as is
  achieved for the table name.

  References: #10920

• [examples] [bug] Fixed the performance example scripts in examples/performance to mostly
  work with the Oracle database, by adding the Identity construct
  to all the tables and allowing primary generation to occur on this backend.
  A few of the "raw DBAPI" cases still are not compatible with Oracle.

sql

• [sql] [bug] Fixed issues in _sql.case() where the logic for determining the
  type of the expression could result in NullType if the last
  element in the "whens" had no type, or in other cases where the type
  could resolve to None. The logic has been updated to scan all
  given expressions so that the first non-null type is used, as well as
  to always ensure a type is present. Pull request courtesy David Evans.

  References: #10843

typing

• [typing] [bug] Fixed the type signature for the PoolEvents.checkin() event to
  indicate that the given DBAPIConnection argument may be None
  in the case where the connection has been invalidated.

postgresql

• [postgresql] [usecase] [reflection] Added support for reflection of PostgreSQL CHECK constraints marked with
  "NO INHERIT", setting the key no_inherit=True in the reflected data.
  Pull request courtesy Ellis Valentiner.

  References: #10777

• [postgresql] [usecase] Support the USING <method> option for PostgreSQL CREATE TABLE to
  specify the access method to use to store the contents for the new table.
  Pull request courtesy Edgar Ramírez-Mondragón.

  References: #10904

• [postgresql] [usecase] Correctly type PostgreSQL RANGE and MULTIRANGE types as Range[T]
  and Sequence[Range[T]].
  Introduced utility sequence _postgresql.MultiRange to allow better
  interoperability of MULTIRANGE types.

  References: #9736

• [postgresql] [usecase] Differentiate between INT4 and INT8 ranges and multi-ranges types when
  inferring the database type from a _postgresql.Range or
  _postgresql.MultiRange instance, preferring INT4 if the values
  fit into it.

• [postgresql] [bug] [regression] Fixed regression in the asyncpg dialect caused by #10717 in
  release 2.0.24 where the change that now attempts to gracefully close the
  asyncpg connection before terminating would not fall back to
  terminate() for other potential connection-related exceptions other
  than a timeout error, not taking into account cases where the graceful
  .close() attempt fails for other reasons such as connection errors.

  References: #10863

• [postgresql] [bug] Fixed an issue regarding the use of the Uuid datatype with the
  Uuid.as_uuid parameter set to False, when using PostgreSQL
  dialects. ORM-optimized INSERT statements (e.g. the "insertmanyvalues"
  feature) would not correctly align primary key UUID values for bulk INSERT
  statements, resulting in errors. Similar issues were fixed for the
  pymssql driver as well.

mysql

• [mysql] [bug] Fixed issue where NULL/NOT NULL would not be properly reflected from a
  MySQL column that also specified the VIRTUAL or STORED directives. Pull
  request courtesy Georg Wicke-Arndt.

  References: #10850

• [mysql] [bug] Fixed issue in asyncio dialects asyncmy and aiomysql, where their
  .close() method is apparently not a graceful close. replace with
  non-standard .ensure_closed() method that's awaitable and move
  .close() to the so-called "terminate" case.

  References: #10893

mssql

• [mssql] [bug] Fixed an issue regarding the use of the Uuid datatype with the
  Uuid.as_uuid parameter set to False, when using the pymssql
  dialect. ORM-optimized INSERT statements (e.g. the "insertmanyvalues"
  feature) would not correctly align primary key UUID values for bulk INSERT
  statements, resulting in errors. Similar issues were fixed for the
  PostgreSQL drivers as well.

oracle

• [oracle] [performance] [bug] Changed the default arraysize of the Oracle dialects so that the value set
  by the driver is used, that is 100 at the time of writing for both
  cx_oracle and oracledb. Previously the value was set to 50 by default. The
  setting of 50 could cause significant performance regressions compared to
  when using cx_oracle/oracledb alone to fetch many hundreds of rows over
  slower networks.

  References: #10877