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