python/python-SQLAlchemy
SHA256
15
0
Fork 0
forked from pool/python-SQLAlchemy
Code Pull Requests Activity

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

Browse Source 
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
This commit is contained in:
Tomáš Chvátal
2020-04-12 07:32:22 +00:00
committed by Git OBS Bridge
parent 7e5a97dcab
commit 4cfdeba561
4 changed files with 106 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

102
python-SQLAlchemy.changes
View File

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