[pkgsrc/trunk]: pkgsrc/databases/py-sqlalchemy py-sqlalchemy: updated to 1.3.13

[adam <adam%pkgsrc.org@localhost>]

details:   https://anonhg.NetBSD.org/pkgsrc/rev/4962e59d3e38
branches:  trunk
changeset: 422825:4962e59d3e38
user:      adam <adam%pkgsrc.org@localhost>
date:      Tue Feb 04 16:57:20 2020 +0000

description:
py-sqlalchemy: updated to 1.3.13

1.3.13

[orm] [bug] [engine]
Added test support and repaired a wide variety of unnecessary reference cycles created for short-lived objects, mostly in the area of ORM queries. Thanks much to Carson Ip for the help on this.

[orm] [bug]
Fixed regression in loader options introduced in 1.3.0b3 via 4468 where the ability to create a loader option using PropComparator.of_type() targeting an aliased entity that is an inheriting subclass 
of the entity which the preceding relationship refers to would fail to produce a matching path. See also 5082 fixed in this same release which involves a similar kind of issue.

[orm] [bug]
Fixed regression in joined eager loading introduced in 1.3.0b3 via 4468 where the ability to create a joined option across a with_polymorphic() into a polymorphic subclass using 
RelationshipProperty.of_type() and then further along regular mapped relationships would fail as the polymorphic subclass would not add itself to the load path in a way that could be located by the 
loader strategy. A tweak has been made to resolve this scenario.

[orm] [bug]
Repaired a warning in the ORM flush process that was not covered by test coverage when deleting objects that use the ?version_id? feature. This warning is generally unreachable unless using a dialect 
that sets the ?supports_sane_rowcount? flag to False, which is not typically the case however is possible for some MySQL configurations as well as older Firebird drivers, and likely some third party 
dialects.

[orm] [bug]
Fixed bug where usage of joined eager loading would not properly wrap the query inside of a subquery when Query.group_by() were used against the query. When any kind of result-limiting approach is 
used, such as DISTINCT, LIMIT, OFFSET, joined eager loading embeds the row-limited query inside of a subquery so that the collection results are not impacted. For some reason, the presence of GROUP 
BY was never included in this criterion, even though it has a similar effect as using DISTINCT. Additionally, the bug would prevent using GROUP BY at all for a joined eager load query for most 
database platforms which forbid non-aggregated, non-grouped columns from being in the query, as the additional columns for the joined eager load would not be accepted by the database.

[orm] [performance]
Identified a performance issue in the system by which a join is constructed based on a mapped relationship. The clause adaption system would be used for the majority of join expressions including in 
the common case where no adaptation is needed. The conditions under which this adaptation occur have been refined so that average non-aliased joins along a simple relationship without a ?secondary? 
table use about 70% less function calls.

[engine] [bug]
Fixed issue where the collection of value processors on a Compiled object would be mutated when ?expanding IN? parameters were used with a datatype that has bind value processors; in particular, this 
would mean that when using statement caching and/or baked queries, the same compiled._bind_processors collection would be mutated concurrently. Since these processors are the same function for a 
given bind parameter namespace every time, there was no actual negative effect of this issue, however, the execution of a Compiled object should never be causing any changes in its state, especially 
given that they are intended to be thread-safe and reusable once fully constructed.

[sql] [usecase]
A function created using GenericFunction can now specify that the name of the function should be rendered with or without quotes by assigning the quoted_name construct to the .name element of the 
object. Prior to 1.3.4, quoting was never applied to function names, and some quoting was introduced in 4467 but no means to force quoting for a mixed case name was available. Additionally, the 
quoted_name construct when used as the name will properly register its lowercase name in the function registry so that the name continues to be available via the func. registry.

[postgresql] [usecase]
Added support for prefixes to the CTE construct, to allow support for Postgresql 12 ?MATERIALIZED? and ?NOT MATERIALIZED? phrases. Pull request courtesy Marat Sharafutdinov.

[postgresql] [bug]
Fixed issue where the PostgreSQL dialect would fail to parse a reflected CHECK constraint that was a boolean-valued function (as opposed to a boolean-valued expression).

[postgresql] [tests]
Improved detection of two phase transactions requirement for the PostgreSQL database by testing that max_prepared_transactions is set to a value greater than 0. Pull request courtesy Federico Caselli.

[mssql] [bug]
Fixed issue where a timezone-aware datetime value being converted to string for use as a parameter value of a mssql.DATETIMEOFFSET column was omitting the fractional seconds.

[bug] [ext]
Fixed bug in sqlalchemy.ext.serializer where a unique BindParameter object could conflict with itself if it were present in the mapping itself, as well as the filter condition of the query, as one 
side would be used against the non-deserialized version and the other side would use the deserialized version. Logic is added to BindParameter similar to its ?clone? method which will uniquify the 
parameter name upon deserialize so that it doesn?t conflict with its original.

[bug] [tests]
Fixed a few test failures which would occur on Windows due to SQLite file locking issues, as well as some timing issues in connection pool related tests; pull request courtesy Federico Caselli.


1.3.12

[orm] [bug]
Fixed issue involving lazy="raise" strategy where an ORM delete of an object would raise for a simple ?use-get? style many-to-one relationship that had lazy=?raise? configured. This is inconsistent 
vs. the change introduced in 1.3 as part of 4353, where it was established that a history operation that does not expect emit SQL should bypass the lazy="raise" check, and instead effectively treat 
it as lazy="raise_on_sql" for this case. The fix adjusts the lazy loader strategy to not raise for the case where the lazy load was instructed that it should not emit SQL if the object were not 
present.

[orm] [bug]
Fixed regression introduced in 1.3.0 related to the association proxy refactor in 4351 that prevented composite() attributes from working in terms of an association proxy that references them.

[orm] [bug]
Setting persistence-related flags on relationship() while also setting viewonly=True will now emit a regular warning, as these flags do not make sense for a viewonly=True relationship. In particular, 
the ?cascade? settings have their own warning that is generated based on the individual values, such as ?delete, delete-orphan?, that should not apply to a viewonly relationship. Note however that in 
the case of ?cascade?, these settings are still erroneously taking effect even though the relationship is set up as ?viewonly?. In 1.4, all persistence-related cascade settings will be disallowed on 
a viewonly=True relationship in order to resolve this issue.

[orm] [bug] [py3k]
Fixed issue where when assigning a collection to itself as a slice, the mutation operation would fail as it would first erase the assigned collection inadvertently. As an assignment that does not 
change the contents should not generate events, the operation is now a no-op. Note that the fix only applies to Python 3; in Python 2, the __setitem__ hook isn?t called in this case; __setslice__ is 
used instead which recreates the list item-by-item in all cases.

[orm] [bug]
Fixed issue where by if the ?begin? of a transaction failed at the Core engine/connection level, such as due to network error or database is locked for some transactional recipes, within the context 
of the Session procuring that connection from the conneciton pool and then immediately returning it, the ORM Session would not close the connection despite this connection not being stored within the 
state of that Session. This would lead to the connection being cleaned out by the connection pool weakref handler within garbage collection which is an unpreferred codepath that in some special 
configurations can emit errors in standard error.

[sql] [bug]
Fixed bug where ?distinct? keyword passed to select() would not treat a string value as a ?label reference? in the same way that the select.distinct() does; it would instead raise unconditionally. 
This keyword argument and the others passed to select() will ultimately be deprecated for SQLAlchemy 2.0.

[sql] [bug]
Changed the text of the exception for ?Can?t resolve label reference? to include other kinds of label coercions, namely that ?DISTINCT? is also in this category under the PostgreSQL dialect.

[sqlite] [bug]
Fixed issue to workaround SQLite?s behavior of assigning ?numeric? affinity to JSON datatypes, first described at Support for SQLite JSON Added, which returns scalar numeric JSON values as a number 
and not as a string that can be JSON deserialized. The SQLite-specific JSON deserializer now gracefully degrades for this case as an exception and bypasses deserialization for single numeric values, 
as from a JSON perspective they are already deserialized.

[mssql] [bug]
Repaired support for the mssql.DATETIMEOFFSET datatype on PyODBC, by adding PyODBC-level result handlers as it does not include native support for this datatype. This includes usage of the Python 3 
?timezone? tzinfo subclass in order to set up a timezone, which on Python 2 makes use of a minimal backport of ?timezone? in sqlalchemy.util.

diffstat:

 databases/py-sqlalchemy/Makefile |   4 ++--
 databases/py-sqlalchemy/distinfo |  10 +++++-----
 2 files changed, 7 insertions(+), 7 deletions(-)

diffs (27 lines):

diff -r 806aba404adf -r 4962e59d3e38 databases/py-sqlalchemy/Makefile
--- a/databases/py-sqlalchemy/Makefile  Tue Feb 04 16:38:22 2020 +0000
+++ b/databases/py-sqlalchemy/Makefile  Tue Feb 04 16:57:20 2020 +0000
@@ -1,6 +1,6 @@
-# $NetBSD: Makefile,v 1.58 2019/12/03 18:19:58 adam Exp $
+# $NetBSD: Makefile,v 1.59 2020/02/04 16:57:20 adam Exp $
 
-DISTNAME=      SQLAlchemy-1.3.11
+DISTNAME=      SQLAlchemy-1.3.13
 PKGNAME=       ${PYPKGPREFIX}-${DISTNAME:tl}
 CATEGORIES=    databases python
 MASTER_SITES=  ${MASTER_SITE_PYPI:=S/SQLAlchemy/}
diff -r 806aba404adf -r 4962e59d3e38 databases/py-sqlalchemy/distinfo
--- a/databases/py-sqlalchemy/distinfo  Tue Feb 04 16:38:22 2020 +0000
+++ b/databases/py-sqlalchemy/distinfo  Tue Feb 04 16:57:20 2020 +0000
@@ -1,6 +1,6 @@
-$NetBSD: distinfo,v 1.53 2019/12/03 18:19:58 adam Exp $
+$NetBSD: distinfo,v 1.54 2020/02/04 16:57:20 adam Exp $
 
-SHA1 (SQLAlchemy-1.3.11.tar.gz) = 64b58f6ae41eb21940ac4c9583da2936c71c77bb
-RMD160 (SQLAlchemy-1.3.11.tar.gz) = 2a05fe18c04e11de8618c9c38029efc9caeeb939
-SHA512 (SQLAlchemy-1.3.11.tar.gz) = c691539db4edd62af749087728dfd424010bfb3ca2cc8503a4b96c1625d059d4c2a748b9a35cc870cc99ca9df61966cce406f9b570b25e55c3632a99b8621e74
-Size (SQLAlchemy-1.3.11.tar.gz) = 6007784 bytes
+SHA1 (SQLAlchemy-1.3.13.tar.gz) = 320ef8780bc92443bcf5dedf7609174865bbe66d
+RMD160 (SQLAlchemy-1.3.13.tar.gz) = 7fbe8fc6213598cf67372f2ce7c578ca81247a04
+SHA512 (SQLAlchemy-1.3.13.tar.gz) = 43ed4fe3505dab775996dc4b01ea729069dee3969f72188f130a942212252d97acb721e51e1a974a2756fdd62b8bf2c626a33f6913d585f669154212da3b783a
+Size (SQLAlchemy-1.3.13.tar.gz) = 6040899 bytes