Bump sqlalchemy from 1.3.20 to 1.4.6

[dependabot]

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

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #64.