Changelog
### 1.4.22
```
:released: July 21, 2021
.. change::
:tags: bug, sql
:tickets: 6786
Fixed issue where use of the :paramref:`_sql.case.whens` parameter passing
a dictionary positionally and not as a keyword argument would emit a 2.0
deprecation warning, referring to the deprecation of passing a list
positionally. The dictionary format of "whens", passed positionally, is
still supported and was accidentally marked as deprecated.
.. change::
:tags: bug, orm
:tickets: 6775
Fixed issue in new :meth:`_schema.Table.table_valued` method where the
resulting :class:`_sql.TableValuedColumn` construct would not respond
correctly to alias adaptation as is used throughout the ORM, such as for
eager loading, polymorphic loading, etc.
.. change::
:tags: bug, orm
:tickets: 6769
Fixed issue where usage of the :meth:`_result.Result.unique` method with an
ORM result that included column expressions with unhashable types, such as
``JSON`` or ``ARRAY`` using non-tuples would silently fall back to using
the ``id()`` function, rather than raising an error. This now raises an
error when the :meth:`_result.Result.unique` method is used in a 2.0 style
ORM query. Additionally, hashability is assumed to be True for result
values of unknown type, such as often happens when using SQL functions of
unknown return type; if values are truly not hashable then the ``hash()``
itself will raise.
For legacy ORM queries, since the legacy :class:`_orm.Query` object
uniquifies in all cases, the old rules remain in place, which is to use
``id()`` for result values of unknown type as this legacy uniquing is
mostly for the purpose of uniquing ORM entities and not column values.
.. change::
:tags: orm, bug
:tickets: 6771
Fixed an issue where clearing of mappers during things like test suite
teardowns could cause a "dictionary changed size" warning during garbage
collection, due to iteration of a weak-referencing dictionary. A ``list()``
has been applied to prevent concurrent GC from affecting this operation.
.. change::
:tags: bug, sql
:tickets: 6770
Fixed issue where type-specific bound parameter handlers would not be
called upon in the case of using the :meth:`_sql.Insert.values` method with
the Python ``None`` value; in particular, this would be noticed when using
the :class:`_types.JSON` datatype as well as related PostgreSQL specific
types such as :class:`_postgresql.JSONB` which would fail to encode the
Python ``None`` value into JSON null, however the issue was generalized to
any bound parameter handler in conjunction with this specific method of
:class:`_sql.Insert`.
.. change::
:tags: bug, engine
:tickets: 6740
Added some guards against ``KeyError`` in the event system to accommodate
the case that the interpreter is shutting down at the same time
:meth:`_engine.Engine.dispose` is being called, which would cause stack
trace warnings.
.. change::
:tags: bug, orm, regression
:tickets: 6793
Fixed critical caching issue where the ORM's persistence feature using
INSERT..RETURNING would cache an incorrect query when mixing the "bulk
save" and standard "flush" forms of INSERT.
.. changelog::
```
### 1.4.21
```
:released: July 14, 2021
.. change::
:tags: usecase, orm
:tickets: 6708
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
:meth:`_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
:paramref:`_orm.relationship.active_history` flag is not set. As is
documented in :meth:`_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
:paramref:`_orm.relationship.active_history` flag can be set to ``True``
on the relationship.
.. change::
:tags: usecase, sql
:tickets: 6752
Added new method :meth:`_sql.HasCTE.add_cte` to each of the
:func:`_sql.select`, :func:`_sql.insert`, :func:`_sql.update` and
:func:`_sql.delete` constructs. This method will add the given
:class:`_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.
.. change::
:tags: bug, postgresql
:tickets: 6755
Fixed issue in :meth:`_postgresql.Insert.on_conflict_do_nothing` and
:meth:`_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.
.. change::
:tags: bug, sql
:tickets: 6710
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.
.. change::
:tags: bug, regression, mssql
:tickets: 6697
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.
.. change::
:tags: orm, regression
:tickets: 6718
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.
.. change::
:tags: bug, postgresql
:tickets: 6739
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.
.. change::
:tags: bug, sql, regression
:tickets: 6735
Fixed regression where the :func:`_sql.tablesample` construct would fail to
be executable when constructed given a floating-point sampling value not
embedded within a SQL function.
.. change::
:tags: bug, postgresql
:tickets: 6696
Fixed issue in :meth:`_postgresql.Insert.on_conflict_do_nothing` and
:meth:`_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.
.. change::
:tags: bug, regression, orm
:tickets: 6698
Fixed regression caused in 1.4.19 due to :ticket:`6503` and related
involving :meth:`_orm.Query.with_entities` where the new structure used
would be inappropriately transferred to an enclosing :class:`_orm.Query`
when making use of set operations such as :meth:`_orm.Query.union`, causing
the JOIN instructions within to be applied to the outside query as well.
.. change::
:tags: bug, orm, regression
:tickets: 6762
Fixed regression which appeared in version 1.4.3 due to :ticket:`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 :func:`_orm.with_polymorphic` against a mapping which
uses a :func:`_orm.column_property` which in turn makes use of a scalar
select that includes a :func:`_orm.aliased` object of the mapped table.
.. changelog::
```
Links
- PyPI: https://pypi.org/project/sqlalchemy
- Changelog: https://pyup.io/changelogs/sqlalchemy/
- Homepage: https://www.sqlalchemy.org
pyup-bot
commented
3 years ago
Update bleach from 3.3.0 to 3.3.1.
Changelog
### 3.3.1 ``` ------------------------------- **Security fixes** None **Features** * add more tests for CVE-2021-23980 / GHSA-vv2x-vrpj-qqpq * bump python version to 3.8 for tox doc, vendorverify, and lint targets * update bug report template tag * update vendorverify script to detect and fail when extra files are vendored * update release process docs to check vendorverify passes locally **Bug fixes** * remove extra vendored django present in the v3.3.0 whl 595 * duplicate h1 header doc fix (thanks Nguyễn Gia Phong / McSinyx!) ```Links
- PyPI: https://pypi.org/project/bleach - Changelog: https://pyup.io/changelogs/bleach/ - Repo: https://github.com/mozilla/bleach - Docs: https://pythonhosted.org/bleach/Update Pillow from 8.3.0 to 8.3.1.
Changelog
### 8.3.1 ``` ------------------ - Catch OSError when checking if fp is sys.stdout 5585 [radarhere] - Handle removing orientation from alternate types of EXIF data 5584 [radarhere] - Make Image.__array__ take optional dtype argument 5572 [t-vi, radarhere] ```Links
- PyPI: https://pypi.org/project/pillow - Changelog: https://pyup.io/changelogs/pillow/ - Homepage: https://python-pillow.orgUpdate SQLAlchemy from 1.4.20 to 1.4.22.
Changelog
### 1.4.22 ``` :released: July 21, 2021 .. change:: :tags: bug, sql :tickets: 6786 Fixed issue where use of the :paramref:`_sql.case.whens` parameter passing a dictionary positionally and not as a keyword argument would emit a 2.0 deprecation warning, referring to the deprecation of passing a list positionally. The dictionary format of "whens", passed positionally, is still supported and was accidentally marked as deprecated. .. change:: :tags: bug, orm :tickets: 6775 Fixed issue in new :meth:`_schema.Table.table_valued` method where the resulting :class:`_sql.TableValuedColumn` construct would not respond correctly to alias adaptation as is used throughout the ORM, such as for eager loading, polymorphic loading, etc. .. change:: :tags: bug, orm :tickets: 6769 Fixed issue where usage of the :meth:`_result.Result.unique` method with an ORM result that included column expressions with unhashable types, such as ``JSON`` or ``ARRAY`` using non-tuples would silently fall back to using the ``id()`` function, rather than raising an error. This now raises an error when the :meth:`_result.Result.unique` method is used in a 2.0 style ORM query. Additionally, hashability is assumed to be True for result values of unknown type, such as often happens when using SQL functions of unknown return type; if values are truly not hashable then the ``hash()`` itself will raise. For legacy ORM queries, since the legacy :class:`_orm.Query` object uniquifies in all cases, the old rules remain in place, which is to use ``id()`` for result values of unknown type as this legacy uniquing is mostly for the purpose of uniquing ORM entities and not column values. .. change:: :tags: orm, bug :tickets: 6771 Fixed an issue where clearing of mappers during things like test suite teardowns could cause a "dictionary changed size" warning during garbage collection, due to iteration of a weak-referencing dictionary. A ``list()`` has been applied to prevent concurrent GC from affecting this operation. .. change:: :tags: bug, sql :tickets: 6770 Fixed issue where type-specific bound parameter handlers would not be called upon in the case of using the :meth:`_sql.Insert.values` method with the Python ``None`` value; in particular, this would be noticed when using the :class:`_types.JSON` datatype as well as related PostgreSQL specific types such as :class:`_postgresql.JSONB` which would fail to encode the Python ``None`` value into JSON null, however the issue was generalized to any bound parameter handler in conjunction with this specific method of :class:`_sql.Insert`. .. change:: :tags: bug, engine :tickets: 6740 Added some guards against ``KeyError`` in the event system to accommodate the case that the interpreter is shutting down at the same time :meth:`_engine.Engine.dispose` is being called, which would cause stack trace warnings. .. change:: :tags: bug, orm, regression :tickets: 6793 Fixed critical caching issue where the ORM's persistence feature using INSERT..RETURNING would cache an incorrect query when mixing the "bulk save" and standard "flush" forms of INSERT. .. changelog:: ``` ### 1.4.21 ``` :released: July 14, 2021 .. change:: :tags: usecase, orm :tickets: 6708 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 :meth:`_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 :paramref:`_orm.relationship.active_history` flag is not set. As is documented in :meth:`_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 :paramref:`_orm.relationship.active_history` flag can be set to ``True`` on the relationship. .. change:: :tags: usecase, sql :tickets: 6752 Added new method :meth:`_sql.HasCTE.add_cte` to each of the :func:`_sql.select`, :func:`_sql.insert`, :func:`_sql.update` and :func:`_sql.delete` constructs. This method will add the given :class:`_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. .. change:: :tags: bug, postgresql :tickets: 6755 Fixed issue in :meth:`_postgresql.Insert.on_conflict_do_nothing` and :meth:`_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. .. change:: :tags: bug, sql :tickets: 6710 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. .. change:: :tags: bug, regression, mssql :tickets: 6697 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. .. change:: :tags: orm, regression :tickets: 6718 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. .. change:: :tags: bug, postgresql :tickets: 6739 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. .. change:: :tags: bug, sql, regression :tickets: 6735 Fixed regression where the :func:`_sql.tablesample` construct would fail to be executable when constructed given a floating-point sampling value not embedded within a SQL function. .. change:: :tags: bug, postgresql :tickets: 6696 Fixed issue in :meth:`_postgresql.Insert.on_conflict_do_nothing` and :meth:`_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. .. change:: :tags: bug, regression, orm :tickets: 6698 Fixed regression caused in 1.4.19 due to :ticket:`6503` and related involving :meth:`_orm.Query.with_entities` where the new structure used would be inappropriately transferred to an enclosing :class:`_orm.Query` when making use of set operations such as :meth:`_orm.Query.union`, causing the JOIN instructions within to be applied to the outside query as well. .. change:: :tags: bug, orm, regression :tickets: 6762 Fixed regression which appeared in version 1.4.3 due to :ticket:`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 :func:`_orm.with_polymorphic` against a mapping which uses a :func:`_orm.column_property` which in turn makes use of a scalar select that includes a :func:`_orm.aliased` object of the mapped table. .. changelog:: ```Links
- PyPI: https://pypi.org/project/sqlalchemy - Changelog: https://pyup.io/changelogs/sqlalchemy/ - Homepage: https://www.sqlalchemy.orgUpdate coveralls from 3.1.0 to 3.2.0.
Changelog
### 3.2.0 ``` Features * **api:** support officially documented generic CI env vars (300) ([ca1c6a47](ca1c6a47)) <a name="3.1.0"></a> ```Links
- PyPI: https://pypi.org/project/coveralls - Changelog: https://pyup.io/changelogs/coveralls/ - Repo: http://github.com/TheKevJames/coveralls-python