From: Mike Bayer Date: Sat, 20 May 2023 00:16:18 +0000 (-0400) Subject: - 2.0.15 X-Git-Tag: rel_2_0_15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b722c8ab24e2379cd19acc6bff0c73e14deaf644;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git - 2.0.15 --- diff --git a/doc/build/changelog/changelog_20.rst b/doc/build/changelog/changelog_20.rst index b82297e350..c9adf3ec25 100644 --- a/doc/build/changelog/changelog_20.rst +++ b/doc/build/changelog/changelog_20.rst @@ -10,7 +10,49 @@ .. changelog:: :version: 2.0.15 - :include_notes_from: unreleased_20 + :released: May 19, 2023 + + .. change:: + :tags: bug, orm + :tickets: 9805 + + As more projects are using new-style "2.0" ORM querying, it's becoming + apparent that the conditional nature of "autoflush", being based on whether + or not the given statement refers to ORM entities, is becoming more of a + key behavior. Up until now, the "ORM" flag for a statement has been loosely + based around whether or not the statement returns rows that correspond to + ORM entities or columns; the original purpose of the "ORM" flag was to + enable ORM-entity fetching rules which apply post-processing to Core result + sets as well as ORM loader strategies to the statement. For statements + that don't build on rows that contain ORM entities, the "ORM" flag was + considered to be mostly unnecessary. + + It still may be the case that "autoflush" would be better taking effect for + *all* usage of :meth:`_orm.Session.execute` and related methods, even for + purely Core SQL constructs. However, this still could impact legacy cases + where this is not expected and may be more of a 2.1 thing. For now however, + the rules for the "ORM-flag" have been opened up so that a statement that + includes ORM entities or attributes anywhere within, including in the WHERE + / ORDER BY / GROUP BY clause alone, within scalar subqueries, etc. will + enable this flag. This will cause "autoflush" to occur for such statements + and also be visible via the :attr:`_orm.ORMExecuteState.is_orm_statement` + event-level attribute. + + + + .. change:: + :tags: bug, postgresql, regression + :tickets: 9808 + + Repaired the base :class:`.Uuid` datatype for the PostgreSQL dialect to + make full use of the PG-specific ``UUID`` dialect-specific datatype when + "native_uuid" is selected, so that PG driver behaviors are included. This + issue became apparent due to the insertmanyvalues improvement made as part + of :ticket:`9618`, where in a similar manner as that of :ticket:`9739`, the + asyncpg driver is very sensitive to datatype casts being present or not, + and the PostgreSQL driver-specific native ``UUID`` datatype must be invoked + when this generic type is used so that these casts take place. + .. changelog:: :version: 2.0.14 diff --git a/doc/build/changelog/unreleased_20/9805.rst b/doc/build/changelog/unreleased_20/9805.rst deleted file mode 100644 index a0b3ce99b1..0000000000 --- a/doc/build/changelog/unreleased_20/9805.rst +++ /dev/null @@ -1,27 +0,0 @@ -.. change:: - :tags: bug, orm - :tickets: 9805 - - As more projects are using new-style "2.0" ORM querying, it's becoming - apparent that the conditional nature of "autoflush", being based on whether - or not the given statement refers to ORM entities, is becoming more of a - key behavior. Up until now, the "ORM" flag for a statement has been loosely - based around whether or not the statement returns rows that correspond to - ORM entities or columns; the original purpose of the "ORM" flag was to - enable ORM-entity fetching rules which apply post-processing to Core result - sets as well as ORM loader strategies to the statement. For statements - that don't build on rows that contain ORM entities, the "ORM" flag was - considered to be mostly unnecessary. - - It still may be the case that "autoflush" would be better taking effect for - *all* usage of :meth:`_orm.Session.execute` and related methods, even for - purely Core SQL constructs. However, this still could impact legacy cases - where this is not expected and may be more of a 2.1 thing. For now however, - the rules for the "ORM-flag" have been opened up so that a statement that - includes ORM entities or attributes anywhere within, including in the WHERE - / ORDER BY / GROUP BY clause alone, within scalar subqueries, etc. will - enable this flag. This will cause "autoflush" to occur for such statements - and also be visible via the :attr:`_orm.ORMExecuteState.is_orm_statement` - event-level attribute. - - diff --git a/doc/build/changelog/unreleased_20/9808.rst b/doc/build/changelog/unreleased_20/9808.rst deleted file mode 100644 index 2294579336..0000000000 --- a/doc/build/changelog/unreleased_20/9808.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. change:: - :tags: bug, postgresql, regression - :tickets: 9808 - - Repaired the base :class:`.Uuid` datatype for the PostgreSQL dialect to - make full use of the PG-specific ``UUID`` dialect-specific datatype when - "native_uuid" is selected, so that PG driver behaviors are included. This - issue became apparent due to the insertmanyvalues improvement made as part - of :ticket:`9618`, where in a similar manner as that of :ticket:`9739`, the - asyncpg driver is very sensitive to datatype casts being present or not, - and the PostgreSQL driver-specific native ``UUID`` datatype must be invoked - when this generic type is used so that these casts take place. - diff --git a/doc/build/conf.py b/doc/build/conf.py index 23532bbbb6..6a9c23451f 100644 --- a/doc/build/conf.py +++ b/doc/build/conf.py @@ -242,9 +242,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.14" +release = "2.0.15" -release_date = "May 18, 2023" +release_date = "May 19, 2023" site_base = os.environ.get("RTD_SITE_BASE", "https://www.sqlalchemy.org") site_adapter_template = "docs_adapter.mako"