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