1.4.23

Released: August 18, 2021

general

• [general] [bug] The setup requirements have been modified such greenlet is a default requirement only for those platforms that are well known for greenlet to be installable and for which there is already a pre-built binary on pypi; the current list is x86_64 aarch64 ppc64le amd64 win32. For other platforms, greenlet will not install by default, which should enable installation and test suite running of SQLAlchemy 1.4 on platforms that don't support greenlet, excluding any asyncio features. In order to install with the greenlet dependency included on a machine architecture outside of the above list, the [asyncio] extra may be included by running pip install sqlalchemy[asyncio] which will then attempt to install greenlet.

  Additionally, the test suite has been repaired so that tests can complete fully when greenlet is not installed, with appropriate skips for asyncio-related tests.

  References: #6136

orm

• [orm] [usecase] Added new attribute _sql.Select.columns_clause_froms that will retrieve the FROM list implied by the columns clause of the _sql.Select statement. This differs from the old _sql.Select.froms collection in that it does not perform any ORM compilation steps, which necessarily deannotate the FROM elements and do things like compute joinedloads etc., which makes it not an appropriate candidate for the _sql.Select.select_from() method. Additionally adds a new parameter _sql.Select.with_only_columns.maintain_column_froms that transfers this collection to _sql.Select.select_from() before replacing the columns collection.

  In addition, the _sql.Select.froms is renamed to _sql.Select.get_final_froms(), to stress that this collection is not a simple accessor and is instead calculated given the full state of the object, which can be an expensive call when used in an ORM context.

  Additionally fixes a regression involving the _orm.with_only_columns() function to support applying criteria to column elements that were replaced with either _sql.Select.with_only_columns() or _orm.Query.with_entities() , which had broken as part of #6503 released in 1.4.19.

  References: #6808

• [orm] [bug] [sql] Fixed issue where a bound parameter object that was "cloned" would cause a name conflict in the compiler, if more than one clone of this parameter were used at the same time in a single statement. This could occur in particular with things like ORM single table inheritance queries that indicated the same "discriminator" value multiple times in one query.

  References: #6824

• [orm] [bug] Fixed issue in loader strategies where the use of the _orm.Load.options() method, particularly when nesting multiple calls, would generate an overly long and more importantly non-deterministic cache key, leading to very large cache keys which were also not allowing efficient cache usage, both in terms of total memory used as well as number of entries used in the cache itself.

  References: #6869

• [orm] [bug] Revised the means by which the _orm.ORMExecuteState.user_defined_options accessor receives _orm.UserDefinedOption and related option objects from the context, with particular emphasis on the "selectinload" on the loader strategy where this previously was not working; other strategies did not have this problem. The objects that are associated with the current query being executed, and not that of a query being cached, are now propagated unconditionally. This essentially separates them out from the "loader strategy" options which are explicitly associated with the compiled state of a query and need to be used in relation to the cached query.

  The effect of this fix is that a user-defined option, such as those used by the dogpile.caching example as well as for other recipes such as defining a "shard id" for the horizontal sharing extension, will be correctly propagated to eager and lazy loaders regardless of whether a cached query was ultimately invoked.

  References: #6887

• [orm] [bug] Fixed issue where the unit of work would internally use a 2.0-deprecated SQL expression form, emitting a deprecation warning when SQLALCHEMY_WARN_20 were enabled.

  References: #6812

• [orm] [bug] Fixed issue in _orm.selectinload() where use of the new _orm.PropComparator.and_() feature within options that were nested more than one level deep would fail to update bound parameter values that were in the nested criteria, as a side effect of SQL statement caching.

  References: #6881

• [orm] [bug] Adjusted ORM loader internals to no longer use the "lambda caching" system that was added in 1.4, as well as repaired one location that was still using the previous "baked query" system for a query. The lambda caching system remains an effective way to reduce the overhead of building up queries that have relatively fixed usage patterns. In the case of loader strategies, the queries used are responsible for moving through lots of arbitrary options and criteria, which is both generated and sometimes consumed by end-user code, that make the lambda cache concept not any more efficient than not using it, at the cost of more complexity. In particular the problems noted by #6881 and #6887 are made are made considerably less complicated by removing this feature internally.

  References: #6079, #6889

• [orm] [bug] Fixed an issue where the _orm.Bundle construct would not create proper cache keys, leading to inefficient use of the query cache. This had some impact on the "selectinload" strategy and was identified as part of #6889.

  References: #6889

sql

• [sql] [bug] Fix issue in _sql.CTE where new _sql.HasCTE.add_cte() method added in version 1.4.21 / #6752 failed to function correctly for "compound select" structures such as _sql.union(), _sql.union_all(), _sql.except(), etc. Pull request courtesy Eric Masseran.

  References: #6752

• [sql] [bug] Fixed an issue in the CacheKey.to_offline_string() method used by the dogpile.caching example where attempting to create a proper cache key from the special "lambda" query generated by the lazy loader would fail to include the parameter values, leading to an incorrect cache key.

  References: #6858

• [sql] [bug] Adjusted the "from linter" warning feature to accommodate for a chain of joins more than one level deep where the ON clauses don't explicitly match up the targets, such as an expression such as "ON TRUE". This mode of use is intended to cancel the cartesian product warning simply by the fact that there's a JOIN from "a to b", which was not working for the case where the chain of joins had more than one element.

  References: #6886

• [sql] [bug] Fixed issue in lambda caching system where an element of a query that produces no cache key, like a custom option or clause element, would still populate the expression in the "lambda cache" inappropriately.

schema

• [schema] [enum] Unify behaviour _schema.Enum in native and non-native implementations regarding the accepted values for an enum with aliased elements. When _schema.Enum.omit_aliases is False all values, alias included, are accepted as valid values. When _schema.Enum.omit_aliases is True only non aliased values are accepted as valid values.

  References: #6146

mypy

• [mypy] [usecase] Added support for SQLAlchemy classes to be defined in user code using "generic class" syntax as defined by sqlalchemy2-stubs, e.g. Column[String], without the need for qualifying these constructs within a TYPE_CHECKING block by implementing the Python special method __class_getitem__(), which allows this syntax to pass without error at runtime.

  References: #6759, #6804

postgresql

• [postgresql] [bug] Added the "is_comparison" flag to the PostgreSQL "overlaps", "contained_by", "contains" operators, so that they work in relevant ORM contexts as well as in conjunction with the "from linter" feature.

  References: #6886

mssql

• [mssql] [bug] [sql] Fixed issue where the literal_binds compiler flag, as used externally to render bound parameters inline, would fail to work when used with a certain class of parameters known as "literal_execute", which covers things like LIMIT and OFFSET values for dialects where the drivers don't allow a bound parameter, such as SQL Server's "TOP" clause. The issue locally seemed to affect only the MSSQL dialect.

  References: #6863

misc

• [bug] [ext] Fixed issue where the horizontal sharding extension would not correctly accommodate for a plain textual SQL statement passed to _orm.Session.execute().

  References: #6816