Hello community,

here is the log from the commit of package python-SQLAlchemy for 
openSUSE:Factory checked in at 2019-04-28 19:59:41
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/python-SQLAlchemy (Old)
 and      /work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.5536 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Package is "python-SQLAlchemy"

Sun Apr 28 19:59:41 2019 rev:63 rq:696966 version:1.3.3

Changes:
--------
--- /work/SRC/openSUSE:Factory/python-SQLAlchemy/python-SQLAlchemy.changes      
2019-04-15 11:50:19.350482519 +0200
+++ 
/work/SRC/openSUSE:Factory/.python-SQLAlchemy.new.5536/python-SQLAlchemy.changes
    2019-04-28 19:59:45.426923946 +0200
@@ -1,0 +2,67 @@
+Sun Apr 21 22:00:19 UTC 2019 - Arun Persaud <[email protected]>
+
+- update to version 1.3.3:
+  * orm
+    + Fixed 1.3 regression in new “ambiguous FROMs” query logic
+      introduced in Query.join() handles ambiguity in deciding the
+      “left” side more explicitly where a Query that explicitly places
+      an entity in the FROM clause with Query.select_from() and also
+      joins to it using Query.join() would later cause an “ambiguous
+      FROM” error if that entity were used in additional joins, as the
+      entity appears twice in the “from” list of the Query. The fix
+      resolves this ambiguity by folding the standalone entity into
+      the join that it’s already a part of in the same way that
+      ultimately happens when the SELECT statement is rendered.
+      References: #4584
+    + Adjusted the Query.filter_by() method to not call and()
+      internally against multiple criteria, instead passing it off to
+      Query.filter() as a series of criteria, instead of a single
+      criteria. This allows Query.filter_by() to defer to
+      Query.filter()’s treatment of variable numbers of clauses,
+      including the case where the list is empty. In this case, the
+      Query object will not have a .whereclause, which allows
+      subsequent “no whereclause” methods like Query.select_from() to
+      behave consistently.  References: #4606
+  * postgresql
+    + Fixed regression from release 1.3.2 caused by #4562 where a URL
+      that contained only a query string and no hostname, such as for
+      the purposes of specifying a service file with connection
+      information, would no longer be propagated to psycopg2
+      properly. The change in #4562 has been adjusted to further suit
+      psycopg2’s exact requirements, which is that if there are any
+      connection parameters whatsoever, the “dsn” parameter is no
+      longer required, so in this case the query string parameters are
+      passed alone.  References: #4601
+  * mssql
+    + Fixed issue in SQL Server dialect where if a bound parameter
+      were present in an ORDER BY expression that would ultimately not
+      be rendered in the SQL Server version of the statement, the
+      parameters would still be part of the execution parameters,
+      leading to DBAPI-level errors. Pull request courtesy Matt
+      Lewellyn.  References: #4587
+  * misc
+    + Fixed behavioral regression as a result of deprecating the
+      “use_threadlocal” flag for Pool, where the SingletonThreadPool
+      no longer makes use of this option which causes the “rollback on
+      return” logic to take place when the same Engine is used
+      multiple times in the context of a transaction to connect or
+      implicitly execute, thereby cancelling the transaction. While
+      this is not the recommended way to work with engines and
+      connections, it is nonetheless a confusing behavioral change as
+      when using SingletonThreadPool, the transaction should stay open
+      regardless of what else is done with the same engine in the same
+      thread. The use_threadlocal flag remains deprecated however the
+      SingletonThreadPool now implements its own version of the same
+      logic.  References: #4585
+    + Fixed bug where using copy.copy() or copy.deepcopy() on
+      MutableList would cause the items within the list to be
+      duplicated, due to an inconsistency in how Python pickle and
+      copy both make use of __getstate__() and __setstate__()
+      regarding lists. In order to resolve, a __reduce_ex__ method had
+      to be added to MutableList. In order to maintain backwards
+      compatibility with existing pickles based on __getstate__(), the
+      __setstate__() method remains as well; the test suite asserts
+      that pickles made against the old version of the class can still
+      be deserialized by the pickle module.  References: #4603
+
+-------------------------------------------------------------------

Old:
----
  SQLAlchemy-1.3.2.tar.gz

New:
----
  SQLAlchemy-1.3.3.tar.gz

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

Other differences:
------------------
++++++ python-SQLAlchemy.spec ++++++
--- /var/tmp/diff_new_pack.AtNJB3/_old  2019-04-28 19:59:46.786923126 +0200
+++ /var/tmp/diff_new_pack.AtNJB3/_new  2019-04-28 19:59:46.790923124 +0200
@@ -19,7 +19,7 @@
 %{?!python_module:%define python_module() python-%{**} python3-%{**}}
 %define oldpython python
 Name:           python-SQLAlchemy
-Version:        1.3.2
+Version:        1.3.3
 Release:        0
 Summary:        Database Abstraction Library
 License:        MIT

++++++ SQLAlchemy-1.3.2.tar.gz -> SQLAlchemy-1.3.3.tar.gz ++++++
++++ 8324 lines of diff (skipped)


Reply via email to