Accepting request 1088037 from home:bnavigator:branches:devel:languages:python

OBS-URL: https://build.opensuse.org/request/show/1088037
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-SQLAlchemy?expand=0&rev=236

python-SQLAlchemy.changes

@@ -1,3 +1,101 @@
+-------------------------------------------------------------------
+Sat May 20 10:32:50 UTC 2023 - Ben Greiner <code@bnavigator.de>
+
+- Update to 2.0.15
+  # orm
+  * 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 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 ORMExecuteState.is_orm_statement event-level attribute.
+    References: #9805
+  # postgresql
+  * Repaired the base 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 #9618, where in a
+    similar manner as that of #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.
+    References: #9808
+- Release 2.0.13
+  # orm
+  * Modified the JoinedLoader implementation to use a simpler
+    approach in one particular area where it previously used a
+    cached structure that would be shared among threads. The
+    rationale is to avoid a potential race condition which is
+    suspected of being the cause of a particular crash that’s been
+    reported multiple times. The cached structure in question is
+    still ultimately “cached” via the compiled SQL cache, so a
+    performance degradation is not anticipated.
+    References: #9777
+  * Fixed regression where use of update() or delete() within a CTE
+    construct, then used in a select(), would raise a CompileError
+    as a result of ORM related rules for performing ORM-level
+    update/delete statements.  
+    References: #9767
+  * Fixed issue in new ORM Annotated Declarative where using a
+    ForeignKey (or other column-level constraint) inside of
+    mapped_column() which is then copied out to models via pep-593
+    Annotated would apply duplicates of each constraint to the
+    Column as produced in the target Table, leading to incorrect
+    CREATE TABLE DDL as well as migration directives under Alembic.
+   References: #9766
+  * Fixed issue where using additional relationship criteria with
+    the joinedload() loader option, where the additional criteria
+    itself contained correlated subqueries that referred to the
+    joined entities and therefore also required “adaption” to
+    aliased entities, would be excluded from this adaption,
+    producing the wrong ON clause for the joinedload.   
+    References: #9779
+  # sql
+  * Generalized the MSSQL try_cast() function into the sqlalchemy.
+    import namespace so that it may be implemented by third party
+    dialects as well. Within SQLAlchemy, the try_cast() function
+    remains a SQL Server-only construct that will raise
+    CompileError if used with backends that don’t support it.
+  * try_cast() implements a CAST where un-castable conversions are
+    returned as NULL, instead of raising an error. Theoretically,
+    the construct could be implemented by third party dialects for
+    Google BigQuery, DuckDB, and Snowflake, and possibly others.
+    Pull request courtesy Nick Crews.
+    References: #9752
+  * Fixed issue in values() construct where an internal compilation
+    error would occur if the construct were used inside of a scalar
+    subquery.
+    References: #9772
+  # postgresql
+  * Fixed apparently very old issue where the ENUM.create_type
+    parameter, when set to its non-default of False, would not be
+    propagated when the Column which it’s a part of were copied, as
+    is common when using ORM Declarative mixins. References: #9773    
+  # tests
+  * Fixed test that relied on the sys.getsizeof() function to not
+    run on pypy, where this function appears to have different
+    behavior than it does on cpython. References: #9789
+- PEP517
+- Add missing runtime requirement
+
 -------------------------------------------------------------------
 Sun May 14 16:30:22 UTC 2023 - Dirk Müller <dmueller@suse.com>