1.4.21

Released: July 14, 2021

orm

• [orm] [usecase] Modified the approach used for history tracking of scalar object relationships that are not many-to-one, i.e. one-to-one relationships that would otherwise be one-to-many. When replacing a one-to-one value, the "old" value that would be replaced is no longer loaded immediately, and is instead handled during the flush process. This eliminates an historically troublesome lazy load that otherwise often occurs when assigning to a one-to-one attribute, and is particularly troublesome when using "lazy='raise'" as well as asyncio use cases.

  This change does cause a behavioral change within the _orm.AttributeEvents.set() event, which is nonetheless currently documented, which is that the event applied to such a one-to-one attribute will no longer receive the "old" parameter if it is unloaded and the _orm.relationship.active_history flag is not set. As is documented in _orm.AttributeEvents.set(), if the event handler needs to receive the "old" value when the event fires off, the active_history flag must be established either with the event listener or with the relationship. This is already the behavior with other kinds of attributes such as many-to-one and column value references.

  The change additionally will defer updating a backref on the "old" value in the less common case that the "old" value is locally present in the session, but isn't loaded on the relationship in question, until the next flush occurs. If this causes an issue, again the normal _orm.relationship.active_history flag can be set to True on the relationship.

  References: #6708

• [orm] [bug] [regression] Fixed regression caused in 1.4.19 due to #6503 and related involving _orm.Query.with_entities() where the new structure used would be inappropriately transferred to an enclosing _orm.Query when making use of set operations such as _orm.Query.union(), causing the JOIN instructions within to be applied to the outside query as well.

  References: #6698

• [orm] [bug] [regression] Fixed regression which appeared in version 1.4.3 due to #6060 where rules that limit ORM adaptation of derived selectables interfered with other ORM-adaptation based cases, in this case when applying adaptations for a _orm.with_polymorphic() against a mapping which uses a _orm.column_property() which in turn makes use of a scalar select that includes a _orm.aliased() object of the mapped table.

  References: #6762

• [orm] [regression] Fixed ORM regression where ad-hoc label names generated for hybrid properties and potentially other similar types of ORM-enabled expressions would usually be propagated outwards through subqueries, allowing the name to be retained in the final keys of the result set even when selecting from subqueries. Additional state is now tracked in this case that isn't lost when a hybrid is selected out of a Core select / subquery.

  References: #6718

sql

• [sql] [usecase] Added new method _sql.HasCTE.add_cte() to each of the _sql.select(), _sql.insert(), _sql.update() and _sql.delete() constructs. This method will add the given _sql.CTE as an "independent" CTE of the statement, meaning it renders in the WITH clause above the statement unconditionally even if it is not otherwise referenced in the primary statement. This is a popular use case on the PostgreSQL database where a CTE is used for a DML statement that runs against database rows independently of the primary statement.

  References: #6752

• [sql] [bug] Fixed issue in CTE constructs where a recursive CTE that referred to a SELECT that has duplicate column names, which are typically deduplicated using labeling logic in 1.4, would fail to refer to the deduplicated label name correctly within the WITH clause.

  References: #6710

• [sql] [bug] [regression] Fixed regression where the _sql.tablesample() construct would fail to be executable when constructed given a floating-point sampling value not embedded within a SQL function.

  References: #6735

postgresql

• [postgresql] [bug] Fixed issue in _postgresql.Insert.on_conflict_do_nothing() and _postgresql.Insert.on_conflict_do_update() where the name of a unique constraint passed as the constraint parameter would not be properly truncated for length if it were based on a naming convention that generated a too-long name for the PostgreSQL max identifier length of 63 characters, in the same way which occurs within a CREATE TABLE statement.

  References: #6755

• [postgresql] [bug] Fixed issue where the PostgreSQL ENUM datatype as embedded in the ARRAY datatype would fail to emit correctly in create/drop when the schema_translate_map feature were also in use. Additionally repairs a related issue where the same schema_translate_map feature would not work for the ENUM datatype in combination with a CAST, that's also intrinsic to how the ARRAY(ENUM) combination works on the PostgreSQL dialect.

  References: #6739

• [postgresql] [bug] Fixed issue in _postgresql.Insert.on_conflict_do_nothing() and _postgresql.Insert.on_conflict_do_update() where the name of a unique constraint passed as the constraint parameter would not be properly quoted if it contained characters which required quoting.

  References: #6696

mssql

• [mssql] [bug] [regression] Fixed regression where the special dotted-schema name handling for the SQL Server dialect would not function correctly if the dotted schema name were used within the schema_translate_map feature.

  References: #6697