From f3e788e034ef6a76868319a4fb48cbf5e0bc9e60 Mon Sep 17 00:00:00 2001 From: Mike Bayer Date: Mon, 6 Feb 2023 18:55:27 -0500 Subject: [PATCH] - 2.0.2 --- doc/build/changelog/changelog_20.rst | 228 ++++++++++++++++++++- doc/build/changelog/unreleased_20/8626.rst | 11 - doc/build/changelog/unreleased_20/8780.rst | 12 -- doc/build/changelog/unreleased_20/9211.rst | 10 - doc/build/changelog/unreleased_20/9217.rst | 10 - doc/build/changelog/unreleased_20/9220.rst | 50 ----- doc/build/changelog/unreleased_20/9226.rst | 9 - doc/build/changelog/unreleased_20/9228.rst | 9 - doc/build/changelog/unreleased_20/9232.rst | 9 - doc/build/changelog/unreleased_20/9237.rst | 40 ---- doc/build/changelog/unreleased_20/9240.rst | 22 -- doc/build/changelog/unreleased_20/9249.rst | 13 -- doc/build/changelog/unreleased_20/9251.rst | 19 -- doc/build/conf.py | 4 +- 14 files changed, 229 insertions(+), 217 deletions(-) delete mode 100644 doc/build/changelog/unreleased_20/8626.rst delete mode 100644 doc/build/changelog/unreleased_20/8780.rst delete mode 100644 doc/build/changelog/unreleased_20/9211.rst delete mode 100644 doc/build/changelog/unreleased_20/9217.rst delete mode 100644 doc/build/changelog/unreleased_20/9220.rst delete mode 100644 doc/build/changelog/unreleased_20/9226.rst delete mode 100644 doc/build/changelog/unreleased_20/9228.rst delete mode 100644 doc/build/changelog/unreleased_20/9232.rst delete mode 100644 doc/build/changelog/unreleased_20/9237.rst delete mode 100644 doc/build/changelog/unreleased_20/9240.rst delete mode 100644 doc/build/changelog/unreleased_20/9249.rst delete mode 100644 doc/build/changelog/unreleased_20/9251.rst diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst index 64bd6c4b3e..8ab6a94d69 100644 --- a/doc/build/changelog/changelog_20.rst +++ b/doc/build/changelog/changelog_20.rst @@ -10,7 +10,233 @@ .. changelog:: :version: 2.0.2 - :include_notes_from: unreleased_20 + :released: February 6, 2023 + + .. change:: + :tags: bug, orm declarative + :tickets: 9249 + + Fixed regression caused by the fix for :ticket:`9171`, which itself was + fixing a regression, involving the mechanics of ``__init__()`` on classes + that extend from :class:`_orm.DeclarativeBase`. The change made it such + that ``__init__()`` was applied to the user-defined base if there were no + ``__init__()`` method directly on the class. This has been adjusted so that + ``__init__()`` is applied only if no other class in the hierarchy of the + user-defined base has an ``__init__()`` method. This again allows + user-defined base classes based on :class:`_orm.DeclarativeBase` to include + mixins that themselves include a custom ``__init__()`` method. + + .. change:: + :tags: bug, mysql, regression + :tickets: 9251 + + Fixed regression caused by issue :ticket:`9058` which adjusted the MySQL + dialect's ``has_table()`` to again use "DESCRIBE", where the specific error + code raised by MySQL version 8 when using a non-existent schema name was + unexpected and failed to be interpreted as a boolean result. + + + + .. change:: + :tags: bug, sqlite + :tickets: 9251 + + Fixed the SQLite dialect's ``has_table()`` function to correctly report + False for queries that include a non-None schema name for a schema that + doesn't exist; previously, a database error was raised. + + + .. change:: + :tags: bug, orm declarative + :tickets: 9226 + + Fixed issue in ORM Declarative Dataclass mappings related to newly added + support for mixins added in 2.0.1 via :ticket:`9179`, where a combination + of using mixins plus ORM inheritance would mis-classify fields in some + cases leading to field-level dataclass arguments such as ``init=False`` being + lost. + + .. change:: + :tags: bug, orm, regression + :tickets: 9232 + + Fixed obscure ORM inheritance issue caused by :ticket:`8705` where some + scenarios of inheriting mappers that indicated groups of columns from the + local table and the inheriting table together under a + :func:`_orm.column_property` would nonetheless warn that properties of the + same name were being combined implicitly. + + .. change:: + :tags: orm, bug, regression + :tickets: 9228 + + Fixed regression where using the :paramref:`_orm.Mapper.version_id_col` + feature with a regular Python-side incrementing column would fail to work + for SQLite and other databases that don't support "rowcount" with + "RETURNING", as "RETURNING" would be assumed for such columns even though + that's not what actually takes place. + + .. change:: + :tags: bug, orm declarative + :tickets: 9240 + + Repaired ORM Declarative mappings to allow for the + :paramref:`_orm.Mapper.primary_key` parameter to be specified within + ``__mapper_args__`` when using :func:`_orm.mapped_column`. Despite this + usage being directly in the 2.0 documentation, the :class:`_orm.Mapper` was + not accepting the :func:`_orm.mapped_column` construct in this context. Ths + feature was already working for the :paramref:`_orm.Mapper.version_id_col` + and :paramref:`_orm.Mapper.polymorphic_on` parameters. + + As part of this change, the ``__mapper_args__`` attribute may be specified + without using :func:`_orm.declared_attr` on a non-mapped mixin class, + including a ``"primary_key"`` entry that refers to :class:`_schema.Column` + or :func:`_orm.mapped_column` objects locally present on the mixin; + Declarative will also translate these columns into the correct ones for a + particular mapped class. This again was working already for the + :paramref:`_orm.Mapper.version_id_col` and + :paramref:`_orm.Mapper.polymorphic_on` parameters. Additionally, + elements within ``"primary_key"`` may be indicated as string names of + existing mapped properties. + + .. change:: + :tags: usecase, sql + :tickets: 8780 + + Added a full suite of new SQL bitwise operators, for performing + database-side bitwise expressions on appropriate data values such as + integers, bit-strings, and similar. Pull request courtesy Yegor Statkevich. + + .. seealso:: + + :ref:`operators_bitwise` + + + .. change:: + :tags: bug, orm declarative + :tickets: 9211 + + An explicit error is raised if a mapping attempts to mix the use of + :class:`_orm.MappedAsDataclass` with + :meth:`_orm.registry.mapped_as_dataclass` within the same class hierarchy, + as this produces issues with the dataclass function being applied at the + wrong time to the mapped class, leading to errors during the mapping + process. + + .. change:: + :tags: bug, orm, regression + :tickets: 9217 + + Fixed regression when using :meth:`_sql.Select.from_statement` in an ORM + context, where matching of columns to SQL labels based on name alone was + disabled for ORM-statements that weren't fully textual. This would prevent + arbitrary SQL expressions with column-name labels from matching up to the + entity to be loaded, which previously would work within the 1.4 + and previous series, so the previous behavior has been restored. + + .. change:: + :tags: bug, asyncio + :tickets: 9237 + + Repaired a regression caused by the fix for :ticket:`8419` which caused + asyncpg connections to be reset (i.e. transaction ``rollback()`` called) + and returned to the pool normally in the case that the connection were not + explicitly returned to the connection pool and was instead being + intercepted by Python garbage collection, which would fail if the garbage + collection operation were being called outside of the asyncio event loop, + leading to a large amount of stack trace activity dumped into logging + and standard output. + + The correct behavior is restored, which is that all asyncio connections + that are garbage collected due to not being explicitly returned to the + connection pool are detached from the pool and discarded, along with a + warning, rather than being returned the pool, as they cannot be reliably + reset. In the case of asyncpg connections, the asyncpg-specific + ``terminate()`` method will be used to end the connection more gracefully + within this process as opposed to just dropping it. + + This change includes a small behavioral change that is hoped to be useful + for debugging asyncio applications, where the warning that's emitted in the + case of asyncio connections being unexpectedly garbage collected has been + made slightly more aggressive by moving it outside of a ``try/except`` + block and into a ``finally:`` block, where it will emit unconditionally + regardless of whether the detach/termination operation succeeded or not. It + will also have the effect that applications or test suites which promote + Python warnings to exceptions will see this as a full exception raise, + whereas previously it was not possible for this warning to actually + propagate as an exception. Applications and test suites which need to + tolerate this warning in the interim should adjust the Python warnings + filter to allow these warnings to not raise. + + The behavior for traditional sync connections remains unchanged, that + garbage collected connections continue to be returned to the pool normally + without emitting a warning. This will likely be changed in a future major + release to at least emit a similar warning as is emitted for asyncio + drivers, as it is a usage error for pooled connections to be intercepted by + garbage collection without being properly returned to the pool. + + .. change:: + :tags: usecase, orm + :tickets: 9220 + + Added new event hook :meth:`_orm.MapperEvents.after_mapper_constructed`, + which supplies an event hook to take place right as the + :class:`_orm.Mapper` object has been fully constructed, but before the + :meth:`_orm.registry.configure` call has been called. This allows code that + can create additional mappings and table structures based on the initial + configuration of a :class:`_orm.Mapper`, which also integrates within + Declarative configuration. Previously, when using Declarative, where the + :class:`_orm.Mapper` object is created within the class creation process, + there was no documented means of running code at this point. The change + is to immediately benefit custom mapping schemes such as that + of the :ref:`examples_versioned_history` example, which generate additional + mappers and tables in response to the creation of mapped classes. + + + .. change:: + :tags: usecase, orm + :tickets: 9220 + + The infrequently used :attr:`_orm.Mapper.iterate_properties` attribute and + :meth:`_orm.Mapper.get_property` method, which are primarily used + internally, no longer implicitly invoke the :meth:`_orm.registry.configure` + process. Public access to these methods is extremely rare and the only + benefit to having :meth:`_orm.registry.configure` would have been allowing + "backref" properties be present in these collections. In order to support + the new :meth:`_orm.MapperEvents.after_mapper_constructed` event, iteration + and access to the internal :class:`_orm.MapperProperty` objects is now + possible without triggering an implicit configure of the mapper itself. + + The more-public facing route to iteration of all mapper attributes, the + :attr:`_orm.Mapper.attrs` collection and similar, will still implicitly + invoke the :meth:`_orm.registry.configure` step thus making backref + attributes available. + + In all cases, the :meth:`_orm.registry.configure` is always available to + be called directly. + + .. change:: + :tags: bug, examples + :tickets: 9220 + + Reworked the :ref:`examples_versioned_history` to work with + version 2.0, while at the same time improving the overall working of + this example to use newer APIs, including a newly added hook + :meth:`_orm.MapperEvents.after_mapper_constructed`. + + + + .. change:: + :tags: bug, mysql + :tickets: 8626 + + Added support for MySQL 8's new ``AS ON DUPLICATE KEY`` syntax when + using :meth:`_mysql.Insert.on_duplicate_key_update`, which is required for + newer versions of MySQL 8 as the previous syntax using ``VALUES()`` now + emits a deprecation warning with those versions. Server version detection + is employed to determine if traditional MariaDB / MySQL < 8 ``VALUES()`` + syntax should be used, vs. the newer MySQL 8 required syntax. Pull request + courtesy Caspar Wylie. .. changelog:: :version: 2.0.1 diff --git a/doc/build/changelog/unreleased_20/8626.rst b/doc/build/changelog/unreleased_20/8626.rst deleted file mode 100644 index c12e803834..0000000000 --- a/doc/build/changelog/unreleased_20/8626.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. change:: - :tags: bug, mysql - :tickets: 8626 - - Added support for MySQL 8's new ``AS ON DUPLICATE KEY`` syntax when - using :meth:`_mysql.Insert.on_duplicate_key_update`, which is required for - newer versions of MySQL 8 as the previous syntax using ``VALUES()`` now - emits a deprecation warning with those versions. Server version detection - is employed to determine if traditional MariaDB / MySQL < 8 ``VALUES()`` - syntax should be used, vs. the newer MySQL 8 required syntax. Pull request - courtesy Caspar Wylie. diff --git a/doc/build/changelog/unreleased_20/8780.rst b/doc/build/changelog/unreleased_20/8780.rst deleted file mode 100644 index 22c20c2b2a..0000000000 --- a/doc/build/changelog/unreleased_20/8780.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. change:: - :tags: usecase, sql - :tickets: 8780 - - Added a full suite of new SQL bitwise operators, for performing - database-side bitwise expressions on appropriate data values such as - integers, bit-strings, and similar. Pull request courtesy Yegor Statkevich. - - .. seealso:: - - :ref:`operators_bitwise` - diff --git a/doc/build/changelog/unreleased_20/9211.rst b/doc/build/changelog/unreleased_20/9211.rst deleted file mode 100644 index 87e256d625..0000000000 --- a/doc/build/changelog/unreleased_20/9211.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. change:: - :tags: bug, orm declarative - :tickets: 9211 - - An explicit error is raised if a mapping attempts to mix the use of - :class:`_orm.MappedAsDataclass` with - :meth:`_orm.registry.mapped_as_dataclass` within the same class hierarchy, - as this produces issues with the dataclass function being applied at the - wrong time to the mapped class, leading to errors during the mapping - process. diff --git a/doc/build/changelog/unreleased_20/9217.rst b/doc/build/changelog/unreleased_20/9217.rst deleted file mode 100644 index 5768357480..0000000000 --- a/doc/build/changelog/unreleased_20/9217.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. change:: - :tags: bug, orm, regression - :tickets: 9217 - - Fixed regression when using :meth:`_sql.Select.from_statement` in an ORM - context, where matching of columns to SQL labels based on name alone was - disabled for ORM-statements that weren't fully textual. This would prevent - arbitrary SQL expressions with column-name labels from matching up to the - entity to be loaded, which previously would work within the 1.4 - and previous series, so the previous behavior has been restored. diff --git a/doc/build/changelog/unreleased_20/9220.rst b/doc/build/changelog/unreleased_20/9220.rst deleted file mode 100644 index f9f0e841de..0000000000 --- a/doc/build/changelog/unreleased_20/9220.rst +++ /dev/null @@ -1,50 +0,0 @@ -.. change:: - :tags: usecase, orm - :tickets: 9220 - - Added new event hook :meth:`_orm.MapperEvents.after_mapper_constructed`, - which supplies an event hook to take place right as the - :class:`_orm.Mapper` object has been fully constructed, but before the - :meth:`_orm.registry.configure` call has been called. This allows code that - can create additional mappings and table structures based on the initial - configuration of a :class:`_orm.Mapper`, which also integrates within - Declarative configuration. Previously, when using Declarative, where the - :class:`_orm.Mapper` object is created within the class creation process, - there was no documented means of running code at this point. The change - is to immediately benefit custom mapping schemes such as that - of the :ref:`examples_versioned_history` example, which generate additional - mappers and tables in response to the creation of mapped classes. - - -.. change:: - :tags: usecase, orm - :tickets: 9220 - - The infrequently used :attr:`_orm.Mapper.iterate_properties` attribute and - :meth:`_orm.Mapper.get_property` method, which are primarily used - internally, no longer implicitly invoke the :meth:`_orm.registry.configure` - process. Public access to these methods is extremely rare and the only - benefit to having :meth:`_orm.registry.configure` would have been allowing - "backref" properties be present in these collections. In order to support - the new :meth:`_orm.MapperEvents.after_mapper_constructed` event, iteration - and access to the internal :class:`_orm.MapperProperty` objects is now - possible without triggering an implicit configure of the mapper itself. - - The more-public facing route to iteration of all mapper attributes, the - :attr:`_orm.Mapper.attrs` collection and similar, will still implicitly - invoke the :meth:`_orm.registry.configure` step thus making backref - attributes available. - - In all cases, the :meth:`_orm.registry.configure` is always available to - be called directly. - -.. change:: - :tags: bug, examples - :tickets: 9220 - - Reworked the :ref:`examples_versioned_history` to work with - version 2.0, while at the same time improving the overall working of - this example to use newer APIs, including a newly added hook - :meth:`_orm.MapperEvents.after_mapper_constructed`. - - diff --git a/doc/build/changelog/unreleased_20/9226.rst b/doc/build/changelog/unreleased_20/9226.rst deleted file mode 100644 index be077d8273..0000000000 --- a/doc/build/changelog/unreleased_20/9226.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. change:: - :tags: bug, orm declarative - :tickets: 9226 - - Fixed issue in ORM Declarative Dataclass mappings related to newly added - support for mixins added in 2.0.1 via :ticket:`9179`, where a combination - of using mixins plus ORM inheritance would mis-classify fields in some - cases leading to field-level dataclass arguments such as ``init=False`` being - lost. diff --git a/doc/build/changelog/unreleased_20/9228.rst b/doc/build/changelog/unreleased_20/9228.rst deleted file mode 100644 index 7e96c24611..0000000000 --- a/doc/build/changelog/unreleased_20/9228.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. change:: - :tags: orm, bug, regression - :tickets: 9228 - - Fixed regression where using the :paramref:`_orm.Mapper.version_id_col` - feature with a regular Python-side incrementing column would fail to work - for SQLite and other databases that don't support "rowcount" with - "RETURNING", as "RETURNING" would be assumed for such columns even though - that's not what actually takes place. diff --git a/doc/build/changelog/unreleased_20/9232.rst b/doc/build/changelog/unreleased_20/9232.rst deleted file mode 100644 index cec6b26eaf..0000000000 --- a/doc/build/changelog/unreleased_20/9232.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. change:: - :tags: bug, orm, regression - :tickets: 9232 - - Fixed obscure ORM inheritance issue caused by :ticket:`8705` where some - scenarios of inheriting mappers that indicated groups of columns from the - local table and the inheriting table together under a - :func:`_orm.column_property` would nonetheless warn that properties of the - same name were being combined implicitly. diff --git a/doc/build/changelog/unreleased_20/9237.rst b/doc/build/changelog/unreleased_20/9237.rst deleted file mode 100644 index 18813cc731..0000000000 --- a/doc/build/changelog/unreleased_20/9237.rst +++ /dev/null @@ -1,40 +0,0 @@ -.. change:: - :tags: bug, asyncio - :tickets: 9237 - - Repaired a regression caused by the fix for :ticket:`8419` which caused - asyncpg connections to be reset (i.e. transaction ``rollback()`` called) - and returned to the pool normally in the case that the connection were not - explicitly returned to the connection pool and was instead being - intercepted by Python garbage collection, which would fail if the garbage - collection operation were being called outside of the asyncio event loop, - leading to a large amount of stack trace activity dumped into logging - and standard output. - - The correct behavior is restored, which is that all asyncio connections - that are garbage collected due to not being explicitly returned to the - connection pool are detached from the pool and discarded, along with a - warning, rather than being returned the pool, as they cannot be reliably - reset. In the case of asyncpg connections, the asyncpg-specific - ``terminate()`` method will be used to end the connection more gracefully - within this process as opposed to just dropping it. - - This change includes a small behavioral change that is hoped to be useful - for debugging asyncio applications, where the warning that's emitted in the - case of asyncio connections being unexpectedly garbage collected has been - made slightly more aggressive by moving it outside of a ``try/except`` - block and into a ``finally:`` block, where it will emit unconditionally - regardless of whether the detach/termination operation succeeded or not. It - will also have the effect that applications or test suites which promote - Python warnings to exceptions will see this as a full exception raise, - whereas previously it was not possible for this warning to actually - propagate as an exception. Applications and test suites which need to - tolerate this warning in the interim should adjust the Python warnings - filter to allow these warnings to not raise. - - The behavior for traditional sync connections remains unchanged, that - garbage collected connections continue to be returned to the pool normally - without emitting a warning. This will likely be changed in a future major - release to at least emit a similar warning as is emitted for asyncio - drivers, as it is a usage error for pooled connections to be intercepted by - garbage collection without being properly returned to the pool. diff --git a/doc/build/changelog/unreleased_20/9240.rst b/doc/build/changelog/unreleased_20/9240.rst deleted file mode 100644 index 8949465f14..0000000000 --- a/doc/build/changelog/unreleased_20/9240.rst +++ /dev/null @@ -1,22 +0,0 @@ -.. change:: - :tags: bug, orm declarative - :tickets: 9240 - - Repaired ORM Declarative mappings to allow for the - :paramref:`_orm.Mapper.primary_key` parameter to be specified within - ``__mapper_args__`` when using :func:`_orm.mapped_column`. Despite this - usage being directly in the 2.0 documentation, the :class:`_orm.Mapper` was - not accepting the :func:`_orm.mapped_column` construct in this context. Ths - feature was already working for the :paramref:`_orm.Mapper.version_id_col` - and :paramref:`_orm.Mapper.polymorphic_on` parameters. - - As part of this change, the ``__mapper_args__`` attribute may be specified - without using :func:`_orm.declared_attr` on a non-mapped mixin class, - including a ``"primary_key"`` entry that refers to :class:`_schema.Column` - or :func:`_orm.mapped_column` objects locally present on the mixin; - Declarative will also translate these columns into the correct ones for a - particular mapped class. This again was working already for the - :paramref:`_orm.Mapper.version_id_col` and - :paramref:`_orm.Mapper.polymorphic_on` parameters. Additionally, - elements within ``"primary_key"`` may be indicated as string names of - existing mapped properties. diff --git a/doc/build/changelog/unreleased_20/9249.rst b/doc/build/changelog/unreleased_20/9249.rst deleted file mode 100644 index ab1ff48fe7..0000000000 --- a/doc/build/changelog/unreleased_20/9249.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. change:: - :tags: bug, orm declarative - :tickets: 9249 - - Fixed regression caused by the fix for :ticket:`9171`, which itself was - fixing a regression, involving the mechanics of ``__init__()`` on classes - that extend from :class:`_orm.DeclarativeBase`. The change made it such - that ``__init__()`` was applied to the user-defined base if there were no - ``__init__()`` method directly on the class. This has been adjusted so that - ``__init__()`` is applied only if no other class in the hierarchy of the - user-defined base has an ``__init__()`` method. This again allows - user-defined base classes based on :class:`_orm.DeclarativeBase` to include - mixins that themselves include a custom ``__init__()`` method. diff --git a/doc/build/changelog/unreleased_20/9251.rst b/doc/build/changelog/unreleased_20/9251.rst deleted file mode 100644 index 23f743cade..0000000000 --- a/doc/build/changelog/unreleased_20/9251.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. change:: - :tags: bug, mysql, regression - :tickets: 9251 - - Fixed regression caused by issue :ticket:`9058` which adjusted the MySQL - dialect's ``has_table()`` to again use "DESCRIBE", where the specific error - code raised by MySQL version 8 when using a non-existent schema name was - unexpected and failed to be interpreted as a boolean result. - - - -.. change:: - :tags: bug, sqlite - :tickets: 9251 - - Fixed the SQLite dialect's ``has_table()`` function to correctly report - False for queries that include a non-None schema name for a schema that - doesn't exist; previously, a database error was raised. - diff --git a/doc/build/conf.py b/doc/build/conf.py index f8807208a2..c8db935da1 100644 --- a/doc/build/conf.py +++ b/doc/build/conf.py @@ -236,9 +236,9 @@ copyright = "2007-2023, the SQLAlchemy authors and contributors" # noqa # The short X.Y version. version = "2.0" # The full version, including alpha/beta/rc tags. -release = "2.0.1" +release = "2.0.2" -release_date = "February 1, 2023" +release_date = "February 6, 2023" site_base = os.environ.get("RTD_SITE_BASE", "https://www.sqlalchemy.org") site_adapter_template = "docs_adapter.mako" -- 2.47.3