1.4.38

Released: June 23, 2022

orm

• [orm] [bug] [regression] Fixed regression caused by #8064 where a particular check for
  column correspondence was made too liberal, resulting in incorrect
  rendering for some ORM subqueries such as those using
  PropComparator.has() or PropComparator.any() in conjunction
  with joined-inheritance queries that also use legacy aliasing features.

  References: #8162

• [orm] [bug] [sql] Fixed an issue where _sql.GenerativeSelect.fetch() would not
  be applied when executing a statement using the ORM.

  References: #8091

• [orm] [bug] Fixed issue where a _orm.with_loader_criteria() option could not be
  pickled, as is necessary when it is carried along for propagation to lazy
  loaders in conjunction with a caching scheme. Currently, the only form that
  is supported as picklable is to pass the "where criteria" as a fixed
  module-level callable function that produces a SQL expression. An ad-hoc
  "lambda" can't be pickled, and a SQL expression object is usually not fully
  picklable directly.

  References: #8109

engine

• [engine] [bug] Repaired a deprecation warning class decorator that was preventing key
  objects such as _engine.Connection from having a proper
  __weakref__ attribute, causing operations like Python standard library
  inspect.getmembers() to fail.

  References: #8115

sql

• [sql] [bug] Fixed multiple observed race conditions related to lambda_stmt(),
  including an initial "dogpile" issue when a new Python code object is
  initially analyzed among multiple simultaneous threads which created both a
  performance issue as well as some internal corruption of state.
  Additionally repaired observed race condition which could occur when
  "cloning" an expression construct that is also in the process of being
  compiled or otherwise accessed in a different thread due to memoized
  attributes altering the __dict__ while iterated, for Python versions
  prior to 3.10; in particular the lambda SQL construct is sensitive to this
  as it holds onto a single statement object persistently. The iteration has
  been refined to use dict.copy() with or without an additional iteration
  instead.

  References: #8098

• [sql] [bug] Enhanced the mechanism of Cast and other "wrapping"
  column constructs to more fully preserve a wrapped Label
  construct, including that the label name will be preserved in the
  .c collection of a Subquery. The label was already
  able to render in the SQL correctly on the outside of the construct
  which it was wrapped inside.

  References: #8084

• [sql] [bug] Adjusted the fix made for #8056 which adjusted the escaping of
  bound parameter names with special characters such that the escaped names
  were translated after the SQL compilation step, which broke a published
  recipe on the FAQ illustrating how to merge parameter names into the string
  output of a compiled SQL string. The change restores the escaped names that
  come from compiled.params and adds a conditional parameter to
  SQLCompiler.construct_params() named escape_names that defaults
  to True, restoring the old behavior by default.

  References: #8113

schema

• [schema] [bug] Fixed bugs involving the Table.include_columns and the
  Table.resolve_fks parameters on Table; these
  little-used parameters were apparently not working for columns that refer
  to foreign key constraints.

  In the first case, not-included columns that refer to foreign keys would
  still attempt to create a ForeignKey object, producing errors
  when attempting to resolve the columns for the foreign key constraint
  within reflection; foreign key constraints that refer to skipped columns
  are now omitted from the table reflection process in the same way as
  occurs for Index and UniqueConstraint objects with the
  same conditions. No warning is produced however, as we likely want to
  remove the include_columns warnings for all constraints in 2.0.

  In the latter case, the production of table aliases or subqueries would
  fail on an FK related table not found despite the presence of
  resolve_fks=False; the logic has been repaired so that if a related
  table is not found, the ForeignKey object is still proxied to the
  aliased table or subquery (these ForeignKey objects are normally
  used in the production of join conditions), but it is sent with a flag that
  it's not resolvable. The aliased table / subquery will then work normally,
  with the exception that it cannot be used to generate a join condition
  automatically, as the foreign key information is missing. This was already
  the behavior for such foreign key constraints produced using non-reflection
  methods, such as joining Table objects from different
  MetaData collections.

  References: #8100, #8101

• [schema] [bug] [mssql] Fixed issue where Table objects that made use of IDENTITY columns
  with a Numeric datatype would produce errors when attempting to
  reconcile the "autoincrement" column, preventing construction of the
  Column from using the Column.autoincrement parameter
  as well as emitting errors when attempting to invoke an Insert
  construct.

  References: #8111

extensions

• [extensions] [bug] Fixed bug in Mutable where pickling and unpickling of an ORM
  mapped instance would not correctly restore state for mappings that
  contained multiple Mutable-enabled attributes.

  References: #8133