2.1.5

Released: October 16, 2026

orm

• [orm] [feature] Added the _orm.Unmapped annotation and the _orm.unmapped_column() construct, providing a declarative-compatible approach to having "excluded" columns in a Declarative model, that is, columns that are part of the _schema.Table but are not mapped, replacing the use of _orm.Mapper.exclude_properties for this purpose when using a Declarative mapping.

  References: #13650

• [orm] [bug] [regression] Fixed regression caused by #11917 in version 2.0.36 where an ORM enabled _sql.update() using WHERE criteria which matched more than one object present in the _orm.Session would expire server-side onupdate columns, as well as columns that were SET to a SQL expression, on only one of the matched objects, leaving the remaining objects with stale values for those attributes. The columns are now expired for all matched objects.

  This change is also backported to: 2.0.55

  References: #13675

• [orm] [deprecated] Using the _orm.Mapper.exclude_properties or _orm.Mapper.include_properties parameters on a Declarative mapping to exclude attributes that are declared on the class, such as with _orm.mapped_column(), is deprecated and now emits a deprecation warning. This use was never supported, and depending on the arguments passed to _orm.mapped_column(), the attribute could remain mapped regardless; in particular, as of 2.1 this includes ORM mapped dataclasses where _orm.mapped_column.default is present. The new _orm.unmapped_column() construct should be used instead. Excluding columns that are present only in the _schema.Table, such as those from __table__, __table_args__ or table reflection, is not affected.

  References: #13650

schema

• [schema] [bug] Fixed issue where dialect-specific keyword arguments established on a ForeignKeyConstraint, ForeignKey or CheckConstraint, such as postgresql_not_valid, were not carried along to the copy of the constraint produced by Table.to_metadata(), so that the copied Table would generate DDL without these options. The fix for #5276 had established this behavior for Column, PrimaryKeyConstraint and UniqueConstraint only.

  This change is also backported to: 2.0.55

  References: #13677

asyncio

• [asyncio] [bug] Fixed issue where a task that was cancelled a second time while the connection pool was closing an asyncio connection invalidated by the first cancellation, such as one received while a statement was executing, would leave the closed connection in place in the pool, where it would be handed out to the next checkout and fail upon first use. The pool now discards the connection in all cases once a close has been attempted. This condition occurs unconditionally for tasks cancelled by an AnyIO cancel scope, which delivers the cancellation repeatedly until the task exits the scope.

  This change is also backported to: 2.0.55

  References: #13673

• [asyncio] [bug] Fixed regression caused by #13548 where an asyncio cancellation delivered while the pool was closing a connection stranded by an exception raised within the _events.PoolEvents.connect() event handler would be suppressed, with the original exception raised in its place. The task would then not end as cancelled, and code that catches ordinary exceptions in order to retry would continue running after it had been cancelled. The CancelledError is now propagated.

  As part of this change, a variety of other cancellation scenarios were caught and repaired.

  This change is also backported to: 2.0.55

  References: #13678