Bump sqlalchemy from 1.3.20 to 1.4.6

Bumps sqlalchemy from 1.3.20 to 1.4.6.

Release notes

Sourced from sqlalchemy's releases.

1.4.6

Released: April 6, 2021

orm

• [orm] [bug] [regression] Fixed regression where a deprecated form of _orm.Query.join() were used, passing a series of entities to join from without any ON clause in a single _orm.Query.join() call, would fail to function correctly.

  References: #6203

• [orm] [bug] [regression] Fixed critical regression where the _orm.Query.yield_per() method in the ORM would set up the internal _engine.Result to yield chunks at a time, however made use of the new _engine.Result.unique() method which uniques across the entire result. This would lead to lost rows since the ORM is using id(obj) as the uniquing function, which leads to repeated identifiers for new objects as already-seen objects are garbage collected. 1.3's behavior here was to "unique" across each chunk, which does not actually produce "uniqued" results when results are yielded in chunks. As the _orm.Query.yield_per() method is already explicitly disallowed when joined eager loading is in place, which is the primary rationale for the "uniquing" feature, the "uniquing" feature is now turned off entirely when _orm.Query.yield_per() is used.

  This regression only applies to the legacy _orm.Query object; when using :term:2.0 style execution, "uniquing" is not automatically applied. To prevent the issue from arising from explicit use of _engine.Result.unique(), an error is now raised if rows are fetched from a "uniqued" ORM-level _engine.Result if any yield per <orm_queryguide_yield_per> API is also in use, as the purpose of yield_per is to allow for arbitrarily large numbers of rows, which cannot be uniqued in memory without growing the number of entries to fit the complete result size.

  Unknown interpreted text role "term".

  References: #6206

sql

• [sql] [bug] [mssql] [oracle] [regression] Fixed further regressions in the same area as that of #6173 released in 1.4.5, where a "postcompile" parameter, again most typically those used for LIMIT/OFFSET rendering in Oracle and SQL Server, would fail to be processed correctly if the same parameter rendered in multiple places in the statement.

  References: #6202

... (truncated)

Commits

• See full diff in compare view