From: Mike Bayer Date: Mon, 16 Sep 2024 20:01:26 +0000 (-0400) Subject: - 2.0.35 X-Git-Tag: rel_2_0_35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=ca501d9d38d50dc4eda52c82ebc9c51766bc141b;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git - 2.0.35 --- diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst index cca32ca1fa..e282c02217 100644 --- a/doc/build/changelog/changelog_20.rst +++ b/doc/build/changelog/changelog_20.rst @@ -10,7 +10,84 @@ .. changelog:: :version: 2.0.35 - :include_notes_from: unreleased_20 + :released: September 16, 2024 + + .. change:: + :tags: bug, orm, typing + :tickets: 11820 + + Fixed issue where it was not possible to use ``typing.Literal`` with + ``Mapped[]`` on Python 3.8 and 3.9. Pull request courtesy Frazer McLean. + + .. change:: + :tags: bug, sqlite, regression + :tickets: 11840 + + The changes made for SQLite CHECK constraint reflection in versions 2.0.33 + and 2.0.34 , :ticket:`11832` and :ticket:`11677`, have now been fully + reverted, as users continued to identify existing use cases that stopped + working after this change. For the moment, because SQLite does not + provide any consistent way of delivering information about CHECK + constraints, SQLAlchemy is limited in what CHECK constraint syntaxes can be + reflected, including that a CHECK constraint must be stated all on a + single, independent line (or inline on a column definition) without + newlines, tabs in the constraint definition or unusual characters in the + constraint name. Overall, reflection for SQLite is tailored towards being + able to reflect CREATE TABLE statements that were originally created by + SQLAlchemy DDL constructs. Long term work on a DDL parser that does not + rely upon regular expressions may eventually improve upon this situation. + A wide range of additional cross-dialect CHECK constraint reflection tests + have been added as it was also a bug that these changes did not trip any + existing tests. + + .. change:: + :tags: orm, bug + :tickets: 11849 + + Fixed issue in ORM evaluator where two datatypes being evaluated with the + SQL concatenator operator would not be checked for + :class:`.UnevaluatableError` based on their datatype; this missed the case + of :class:`_postgresql.JSONB` values being used in a concatenate operation + which is supported by PostgreSQL as well as how SQLAlchemy renders the SQL + for this operation, but does not work at the Python level. By implementing + :class:`.UnevaluatableError` for this combination, ORM update statements + will now fall back to "expire" when a concatenated JSON value used in a SET + clause is to be synchronized to a Python object. + + .. change:: + :tags: bug, orm + :tickets: 11853 + + An warning is emitted if :func:`_orm.joinedload` or + :func:`_orm.subqueryload` are used as a top level option against a + statement that is not a SELECT statement, such as with an + ``insert().returning()``. There are no JOINs in INSERT statements nor is + there a "subquery" that can be repurposed for subquery eager loading, and + for UPDATE/DELETE joinedload does not support these either, so it is never + appropriate for this use to pass silently. + + .. change:: + :tags: bug, orm + :tickets: 11855 + + Fixed issue where using loader options such as :func:`_orm.selectinload` + with additional criteria in combination with ORM DML such as + :func:`_sql.insert` with RETURNING would not correctly set up internal + contexts required for caching to work correctly, leading to incorrect + results. + + .. change:: + :tags: bug, mysql + :tickets: 11870 + + Fixed issue in mariadbconnector dialect where query string arguments that + weren't checked integer or boolean arguments would be ignored, such as + string arguments like ``unix_socket``, etc. As part of this change, the + argument parsing for particular elements such as ``client_flags``, + ``compress``, ``local_infile`` has been made more consistent across all + MySQL / MariaDB dialect which accept each argument. Pull request courtesy + Tobias Alex-Petersen. + .. changelog:: :version: 2.0.34 diff --git a/doc/build/changelog/unreleased_20/11820.rst b/doc/build/changelog/unreleased_20/11820.rst deleted file mode 100644 index 3f76d30bee..0000000000 --- a/doc/build/changelog/unreleased_20/11820.rst +++ /dev/null @@ -1,6 +0,0 @@ -.. change:: - :tags: bug, orm, typing - :tickets: 11820 - - Fixed issue where it was not possible to use ``typing.Literal`` with - ``Mapped[]`` on Python 3.8 and 3.9. Pull request courtesy Frazer McLean. diff --git a/doc/build/changelog/unreleased_20/11840.rst b/doc/build/changelog/unreleased_20/11840.rst deleted file mode 100644 index 42074e3d2b..0000000000 --- a/doc/build/changelog/unreleased_20/11840.rst +++ /dev/null @@ -1,20 +0,0 @@ -.. change:: - :tags: bug, sqlite, regression - :tickets: 11840 - - The changes made for SQLite CHECK constraint reflection in versions 2.0.33 - and 2.0.34 , :ticket:`11832` and :ticket:`11677`, have now been fully - reverted, as users continued to identify existing use cases that stopped - working after this change. For the moment, because SQLite does not - provide any consistent way of delivering information about CHECK - constraints, SQLAlchemy is limited in what CHECK constraint syntaxes can be - reflected, including that a CHECK constraint must be stated all on a - single, independent line (or inline on a column definition) without - newlines, tabs in the constraint definition or unusual characters in the - constraint name. Overall, reflection for SQLite is tailored towards being - able to reflect CREATE TABLE statements that were originally created by - SQLAlchemy DDL constructs. Long term work on a DDL parser that does not - rely upon regular expressions may eventually improve upon this situation. - A wide range of additional cross-dialect CHECK constraint reflection tests - have been added as it was also a bug that these changes did not trip any - existing tests. diff --git a/doc/build/changelog/unreleased_20/11849.rst b/doc/build/changelog/unreleased_20/11849.rst deleted file mode 100644 index 4a274702ec..0000000000 --- a/doc/build/changelog/unreleased_20/11849.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. change:: - :tags: orm, bug - :tickets: 11849 - - Fixed issue in ORM evaluator where two datatypes being evaluated with the - SQL concatenator operator would not be checked for - :class:`.UnevaluatableError` based on their datatype; this missed the case - of :class:`_postgresql.JSONB` values being used in a concatenate operation - which is supported by PostgreSQL as well as how SQLAlchemy renders the SQL - for this operation, but does not work at the Python level. By implementing - :class:`.UnevaluatableError` for this combination, ORM update statements - will now fall back to "expire" when a concatenated JSON value used in a SET - clause is to be synchronized to a Python object. diff --git a/doc/build/changelog/unreleased_20/11853.rst b/doc/build/changelog/unreleased_20/11853.rst deleted file mode 100644 index 92e6abdb68..0000000000 --- a/doc/build/changelog/unreleased_20/11853.rst +++ /dev/null @@ -1,11 +0,0 @@ -.. change:: - :tags: bug, orm - :tickets: 11853 - - An warning is emitted if :func:`_orm.joinedload` or - :func:`_orm.subqueryload` are used as a top level option against a - statement that is not a SELECT statement, such as with an - ``insert().returning()``. There are no JOINs in INSERT statements nor is - there a "subquery" that can be repurposed for subquery eager loading, and - for UPDATE/DELETE joinedload does not support these either, so it is never - appropriate for this use to pass silently. diff --git a/doc/build/changelog/unreleased_20/11855.rst b/doc/build/changelog/unreleased_20/11855.rst deleted file mode 100644 index cee30cf8b3..0000000000 --- a/doc/build/changelog/unreleased_20/11855.rst +++ /dev/null @@ -1,9 +0,0 @@ -.. change:: - :tags: bug, orm - :tickets: 11855 - - Fixed issue where using loader options such as :func:`_orm.selectinload` - with additional criteria in combination with ORM DML such as - :func:`_sql.insert` with RETURNING would not correctly set up internal - contexts required for caching to work correctly, leading to incorrect - results. diff --git a/doc/build/changelog/unreleased_20/11870.rst b/doc/build/changelog/unreleased_20/11870.rst deleted file mode 100644 index 9625a20f8c..0000000000 --- a/doc/build/changelog/unreleased_20/11870.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. change:: - :tags: bug, mysql - :tickets: 11870 - - Fixed issue in mariadbconnector dialect where query string arguments that - weren't checked integer or boolean arguments would be ignored, such as - string arguments like ``unix_socket``, etc. As part of this change, the - argument parsing for particular elements such as ``client_flags``, - ``compress``, ``local_infile`` has been made more consistent across all - MySQL / MariaDB dialect which accept each argument. Pull request courtesy - Tobias Alex-Petersen. - diff --git a/doc/build/conf.py b/doc/build/conf.py index a21225dded..6e8a9ee943 100644 --- a/doc/build/conf.py +++ b/doc/build/conf.py @@ -244,9 +244,9 @@ copyright = "2007-2024, 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.34" +release = "2.0.35" -release_date = "September 4, 2024" +release_date = "September 16, 2024" site_base = os.environ.get("RTD_SITE_BASE", "https://www.sqlalchemy.org") site_adapter_template = "docs_adapter.mako"