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