Script 'mail_helper' called by obssrc
Hello community,

here is the log from the commit of package python-SQLAlchemy for 
openSUSE:Factory checked in at 2022-07-12 11:12:01
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old)
 and      /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1523 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "python-SQLAlchemy"

Tue Jul 12 11:12:01 2022 rev:98 rq:988284 version:1.4.39

Changes:
--------
--- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes      
2022-06-17 21:22:24.682770069 +0200
+++ 
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1523/python-SQLAlchemy.changes
    2022-07-12 11:12:06.059671869 +0200
@@ -1,0 +2,108 @@
+Sat Jul  9 14:12:13 UTC 2022 - Arun Persaud <a...@gmx.de>
+
+- update to version 1.4.39:
+  * orm
+    + [orm] [bug] [regression] Fixed regression caused by #8133 where
+      the pickle format for mutable attributes was changed, without a
+      fallback to recognize the old format, causing in-place upgrades
+      of SQLAlchemy to no longer be able to read pickled data from
+      previous versions. A check plus a fallback for the old format is
+      now in place.  References: #8133
+
+- changes from version 1.4.38:
+  * orm
+    + [orm] [bug] [regression] Fixed regression caused by #8064 where
+      a particular check for column correspondence was made too
+      liberal, resulting in incorrect rendering for some ORM
+      subqueries such as those using PropComparator.has() or
+      PropComparator.any() in conjunction with joined-inheritance
+      queries that also use legacy aliasing features.  References:
+      #8162
+    + [orm] [bug] [sql] Fixed an issue where GenerativeSelect.fetch()
+      would not be applied when executing a statement using the ORM.
+      References: #8091
+    + [orm] [bug] Fixed issue where a with_loader_criteria() option
+      could not be pickled, as is necessary when it is carried along
+      for propagation to lazy loaders in conjunction with a caching
+      scheme. Currently, the only form that is supported as picklable
+      is to pass the ???where criteria??? as a fixed module-level callable
+      function that produces a SQL expression. An ad-hoc ???lambda???
+      can???t be pickled, and a SQL expression object is usually not
+      fully picklable directly.  References: #8109
+  * engine
+    + [engine] [bug] Repaired a deprecation warning class decorator
+      that was preventing key objects such as Connection from having a
+      proper __weakref__ attribute, causing operations like Python
+      standard library inspect.getmembers() to fail.  References:
+      #8115
+  * sql
+    + [sql] [bug] Fixed multiple observed race conditions related to
+      lambda_stmt(), including an initial ???dogpile??? issue when a new
+      Python code object is initially analyzed among multiple
+      simultaneous threads which created both a performance issue as
+      well as some internal corruption of state. Additionally repaired
+      observed race condition which could occur when ???cloning??? an
+      expression construct that is also in the process of being
+      compiled or otherwise accessed in a different thread due to
+      memoized attributes altering the __dict__ while iterated, for
+      Python versions prior to 3.10; in particular the lambda SQL
+      construct is sensitive to this as it holds onto a single
+      statement object persistently. The iteration has been refined to
+      use dict.copy() with or without an additional iteration instead.
+      References: #8098
+    + [sql] [bug] Enhanced the mechanism of Cast and other ???wrapping???
+      column constructs to more fully preserve a wrapped Label
+      construct, including that the label name will be preserved in
+      the .c collection of a Subquery. The label was already able to
+      render in the SQL correctly on the outside of the construct
+      which it was wrapped inside.  References: #8084
+    + [sql] [bug] Adjusted the fix made for #8056 which adjusted the
+      escaping of bound parameter names with special characters such
+      that the escaped names were translated after the SQL compilation
+      step, which broke a published recipe on the FAQ illustrating how
+      to merge parameter names into the string output of a compiled
+      SQL string. The change restores the escaped names that come from
+      compiled.params and adds a conditional parameter to
+      SQLCompiler.construct_params() named escape_names that defaults
+      to True, restoring the old behavior by default.  References:
+      #8113
+  * schema
+    + [schema] [bug] Fixed bugs involving the Table.include_columns
+      and the Table.resolve_fks parameters on Table; these little-used
+      parameters were apparently not working for columns that refer to
+      foreign key constraints.  In the first case, not-included
+      columns that refer to foreign keys would still attempt to create
+      a ForeignKey object, producing errors when attempting to resolve
+      the columns for the foreign key constraint within reflection;
+      foreign key constraints that refer to skipped columns are now
+      omitted from the table reflection process in the same way as
+      occurs for Index and UniqueConstraint objects with the same
+      conditions. No warning is produced however, as we likely want to
+      remove the include_columns warnings for all constraints in 2.0.
+      In the latter case, the production of table aliases or
+      subqueries would fail on an FK related table not found despite
+      the presence of resolve_fks=False; the logic has been repaired
+      so that if a related table is not found, the ForeignKey object
+      is still proxied to the aliased table or subquery (these
+      ForeignKey objects are normally used in the production of join
+      conditions), but it is sent with a flag that it???s not
+      resolvable. The aliased table / subquery will then work
+      normally, with the exception that it cannot be used to generate
+      a join condition automatically, as the foreign key information
+      is missing. This was already the behavior for such foreign key
+      constraints produced using non-reflection methods, such as
+      joining Table objects from different MetaData collections.
+      References: #8100, #8101
+    + [schema] [bug] [mssql] Fixed issue where Table objects that made
+      use of IDENTITY columns with a Numeric datatype would produce
+      errors when attempting to reconcile the ???autoincrement??? column,
+      preventing construction of the Column from using the
+      Column.autoincrement parameter as well as emitting errors when
+      attempting to invoke an Insert construct.  References: #8111
+  * extensions
+    + [extensions] [bug] Fixed bug in Mutable where pickling and
+      unpickling of an ORM mapped instance would not correctly restore
+      state for mappings that contained multiple Mutable-enabled
+      attributes.  References: #8133
+
+-------------------------------------------------------------------

Old:
----
  SQLAlchemy-1.4.37.tar.gz

New:
----
  SQLAlchemy-1.4.39.tar.gz

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Other differences:
------------------
++++++ python-SQLAlchemy.spec ++++++
--- /var/tmp/diff_new_pack.zOdSkI/_old  2022-07-12 11:12:06.707672718 +0200
+++ /var/tmp/diff_new_pack.zOdSkI/_new  2022-07-12 11:12:06.711672723 +0200
@@ -20,7 +20,7 @@
 %define skip_python2 1
 %define oldpython python
 Name:           python-SQLAlchemy
-Version:        1.4.37
+Version:        1.4.39
 Release:        0
 Summary:        Database Abstraction Library
 License:        MIT

++++++ SQLAlchemy-1.4.37.tar.gz -> SQLAlchemy-1.4.39.tar.gz ++++++
/work/SRC/openSUSE:Factory/python-SQLAlchemy/SQLAlchemy-1.4.37.tar.gz 
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.1523/SQLAlchemy-1.4.39.tar.gz 
differ: char 5, line 1

Reply via email to