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

update to latest version

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

SQLAlchemy-1.3.15.tar.gz

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

SQLAlchemy-1.3.16.tar.gz

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

python-SQLAlchemy.changes

@@ -1,3 +1,105 @@
+-------------------------------------------------------------------
+Thu Apr  9 16:23:41 UTC 2020 - Arun Persaud <arun@gmx.de>
+
+- update to version 1.3.16:
+  * orm
+    + Fixed bug in orm.selectinload() loading option where two or more
+      loaders that represent different relationships with the same
+      string key name as referenced from a single
+      orm.with_polymorphic() construct with multiple subclass mappers
+      would fail to invoke each subqueryload separately, instead
+      making use of a single string-based slot that would prevent the
+      other loaders from being invoked.  References: #5228
+    + Fixed issue where a lazyload that uses session-local “get”
+      against a target many-to-one relationship where an object with
+      the correct primary key is present, however it’s an instance of
+      a sibling class, does not correctly return None as is the case
+      when the lazy loader actually emits a load for that row.
+      References: #5210
+    + Modified the queries used by subqueryload and selectinload to no
+      longer ORDER BY the primary key of the parent entity; this
+      ordering was there to allow the rows as they come in to be
+      copied into lists directly with a minimal level of Python-side
+      collation. However, these ORDER BY clauses can negatively impact
+      the performance of the query as in many scenarios these columns
+      are derived from a subquery or are otherwise not actual primary
+      key columns such that SQL planners cannot make use of
+      indexes. The Python-side collation uses the native
+      itertools.group_by() to collate the incoming rows, and has been
+      modified to allow multiple row-groups-per-parent to be assembled
+      together using list.extend(), which should still allow for
+      relatively fast Python-side performance. There will still be an
+      ORDER BY present for a relationship that includes an explicit
+      order_by parameter, however this is the only ORDER BY that will
+      be added to the query for both kinds of loading.  References:
+      #5162
+  * orm declarative
+    + The string argument accepted as the first positional argument by
+      the relationship() function when using the Declarative API is no
+      longer interpreted using the Python eval() function; instead,
+      the name is dot separated and the names are looked up directly
+      in the name resolution dictionary without treating the value as
+      a Python expression. However, passing a string argument to the
+      other relationship() parameters that necessarily must accept
+      Python expressions will still use eval(); the documentation has
+      been clarified to ensure that there is no ambiguity that this is
+      in use.  See also Evaluation of relationship arguments - details
+      on string evaluation References: #5238
+  * sql
+    + Add ability to literal compile a DateTime, Date or :class:”Time”
+      when using the string dialect for debugging purposes. This
+      change does not impact real dialect implementation that retain
+      their current behavior.  References: #5052
+  * schema
+    + Added support for reflection of “computed” columns, which are
+      now returned as part of the structure returned by
+      Inspector.get_columns(). When reflecting full Table objects,
+      computed columns will be represented using the Computed
+      construct.  References: #5063
+  * postgresql
+    + Fixed issue where a “covering” index, e.g. those which have an
+      INCLUDE clause, would be reflected including all the columns in
+      INCLUDE clause as regular columns. A warning is now emitted if
+      these additional columns are detected indicating that they are
+      currently ignored. Note that full support for “covering” indexes
+      is part of #4458. Pull request courtesy Marat Sharafutdinov.
+      References: #5205
+  * mysql
+    + Fixed issue in MySQL dialect when connecting to a psuedo-MySQL
+      database such as that provided by ProxySQL, the up front check
+      for isolation level when it returns no row will not prevent the
+      dialect from continuing to connect. A warning is emitted that
+      the isolation level could not be detected.  References: #5239
+  * sqlite
+    + Implemented AUTOCOMMIT isolation level for SQLite when using
+      pysqlite.  References: #5164
+  * mssql
+    + Added support for ColumnOperators.is_distinct_from() and
+      ColumnOperators.isnot_distinct_from() to SQL Server, MySQL, and
+      Oracle.  References: #5137
+  * oracle
+    + Implemented AUTOCOMMIT isolation level for Oracle when using
+      cx_Oracle. Also added a fixed default isolation level of READ
+      COMMITTED for Oracle.  References: #5200
+    + Fixed regression / incorrect fix caused by fix for #5146 where
+      the Oracle dialect reads from the “all_tab_comments” view to get
+      table comments but fails to accommodate for the current owner of
+      the table being requested, causing it to read the wrong comment
+      if multiple tables of the same name exist in multiple schemas.
+      References: #5146
+  * misc
+    + Fixed an issue that prevented the test suite from running with
+      the recently released py.test 5.4.0.  References: #5201
+    + Enum type now supports the parameter Enum.length to specify the
+      length of the VARCHAR column to create when using non native
+      enums by setting Enum.native_enum to False References: #5183
+    + Ensured that the “pyproject.toml” file is not included in
+      builds, as the presence of this file indicates to pip that a
+      pep-517 installation process should be used. As this mode of
+      operation appears to be not well supported by current tools /
+      distros, these problems are avoided within the scope of
+      SQLAlchemy installation by omitting the file.  References: #5207
+
 -------------------------------------------------------------------
 Sat Mar 14 12:26:48 UTC 2020 - Dirk Mueller <dmueller@suse.com>
 

python-SQLAlchemy.spec

@@ -19,7 +19,7 @@
 %{?!python_module:%define python_module() python-%{**} python3-%{**}}
 %define oldpython python
 Name:           python-SQLAlchemy
-Version:        1.3.15
+Version:        1.3.16
 Release:        0
 Summary:        Database Abstraction Library
 License:        MIT