Accepting request 696509 from home:apersaud:branches:devel:languages:python

update to latest version

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

SQLAlchemy-1.3.2.tar.gz

@@ -1,3 +0,0 @@
-version https://git-lfs.github.com/spec/v1
-oid sha256:d5432832f91d200c3d8b473a266d59442d825f9ea744c467e68c5d9a9479fbce
-size 5851340

SQLAlchemy-1.3.3.tar.gz

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:91c54ca8345008fceaec987e10924bf07dcab36c442925357e5a467b36a38319
+size 5864870

python-SQLAlchemy.changes

@@ -1,3 +1,70 @@
+-------------------------------------------------------------------
+Sun Apr 21 22:00:19 UTC 2019 - Arun Persaud <arun@gmx.de>
+
+- 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
+
 -------------------------------------------------------------------
 Wed Apr 10 15:37:48 UTC 2019 - Arun Persaud <arun@gmx.de>
 

python-SQLAlchemy.spec

@@ -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