pool/python-SQLAlchemy
SHA256
17
0
Fork 2
Code Issues Pull Requests Activity

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

Browse Source 
update to latest version

OBS-URL: https://build.opensuse.org/request/show/908093
OBS-URL: https://build.opensuse.org/package/show/devel:languages:python/python-SQLAlchemy?expand=0&rev=195
This commit is contained in:
Matej Cepl
2021-07-26 14:32:47 +00:00
committed by Git OBS Bridge
parent 6d5c08c7bd
commit 08ebb0d6ac
4 changed files with 149 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

145
python-SQLAlchemy.changes
View File

@@ -1,3 +1,148 @@
-------------------------------------------------------------------
Thu Jul 22 01:35:15 UTC 2021 - Arun Persaud <arun@gmx.de>
- update to version 1.4.22:
* orm
+ Fixed issue in new Table.table_valued() method where the
resulting TableValuedColumn construct would not respond
correctly to alias adaptation as is used throughout the ORM,
such as for eager loading, polymorphic loading, etc.
+ Fixed issue where usage of the Result.unique() method with an
ORM result that included column expressions with unhashable
types, such as JSON or ARRAY using non-tuples would silently
fall back to using the id() function, rather than raising an
error. This now raises an error when the Result.unique() method
is used in a 2.0 style ORM query. Additionally, hashability is
assumed to be True for result values of unknown type, such as
often happens when using SQL functions of unknown return type;
if values are truly not hashable then the hash() itself will
raise.
+ For legacy ORM queries, since the legacy Query object uniquifies
in all cases, the old rules remain in place, which is to use
id() for result values of unknown type as this legacy uniquing
is mostly for the purpose of uniquing ORM entities and not
column values.
+ Fixed an issue where clearing of mappers during things like test
suite teardowns could cause a “dictionary changed size” warning
during garbage collection, due to iteration of a
weak-referencing dictionary. A list() has been applied to
prevent concurrent GC from affecting this operation.
+ Fixed critical caching issue where the ORM’s persistence feature
using INSERT..RETURNING would cache an incorrect query when
mixing the “bulk save” and standard “flush” forms of INSERT.
* engine
+ Added some guards against KeyError in the event system to
accommodate the case that the interpreter is shutting down at
the same time Engine.dispose() is being called, which would
cause stack trace warnings.
* sql
+ Fixed issue where use of the case.whens parameter passing a
dictionary positionally and not as a keyword argument would emit
a 2.0 deprecation warning, referring to the deprecation of
passing a list positionally. The dictionary format of “whens”,
passed positionally, is still supported and was accidentally
marked as deprecated.
+ Fixed issue where type-specific bound parameter handlers would
not be called upon in the case of using the Insert.values()
method with the Python None value; in particular, this would be
noticed when using the JSON datatype as well as related
PostgreSQL specific types such as JSONB which would fail to
encode the Python None value into JSON null, however the issue
was generalized to any bound parameter handler in conjunction
with this specific method of Insert.
- changes from version 1.4.21:
* orm
+ Modified the approach used for history tracking of scalar object
relationships that are not many-to-one, i.e. one-to-one
relationships that would otherwise be one-to-many. When
replacing a one-to-one value, the “old” value that would be
replaced is no longer loaded immediately, and is instead handled
during the flush process. This eliminates an historically
troublesome lazy load that otherwise often occurs when assigning
to a one-to-one attribute, and is particularly troublesome when
using “lazy=’raise’” as well as asyncio use cases.
+ This change does cause a behavioral change within the
AttributeEvents.set() event, which is nonetheless currently
documented, which is that the event applied to such a one-to-one
attribute will no longer receive the “old” parameter if it is
unloaded and the relationship.active_history flag is not set. As
is documented in AttributeEvents.set(), if the event handler
needs to receive the “old” value when the event fires off, the
active_history flag must be established either with the event
listener or with the relationship. This is already the behavior
with other kinds of attributes such as many-to-one and column
value references.
+ The change additionally will defer updating a backref on the
“old” value in the less common case that the “old” value is
locally present in the session, but isn’t loaded on the
relationship in question, until the next flush occurs. If this
causes an issue, again the normal relationship.active_history
flag can be set to True on the relationship.
+ Fixed regression caused in 1.4.19 due to #6503 and related
involving Query.with_entities() where the new structure used
would be inappropriately transferred to an enclosing Query when
making use of set operations such as Query.union(), causing the
JOIN instructions within to be applied to the outside query as
well.
+ Fixed regression which appeared in version 1.4.3 due to #6060
where rules that limit ORM adaptation of derived selectables
interfered with other ORM-adaptation based cases, in this case
when applying adaptations for a with_polymorphic() against a
mapping which uses a column_property() which in turn makes use
of a scalar select that includes a aliased() object of the
mapped table.
+ Fixed ORM regression where ad-hoc label names generated for
hybrid properties and potentially other similar types of
ORM-enabled expressions would usually be propagated outwards
through subqueries, allowing the name to be retained in the
final keys of the result set even when selecting from
subqueries. Additional state is now tracked in this case that
isn’t lost when a hybrid is selected out of a Core select /
subquery.
* sql
+ Added new method HasCTE.add_cte() to each of the select(),
insert(), update() and delete() constructs. This method will add
the given CTE as an “independent” CTE of the statement, meaning
it renders in the WITH clause above the statement
unconditionally even if it is not otherwise referenced in the
primary statement. This is a popular use case on the PostgreSQL
database where a CTE is used for a DML statement that runs
against database rows independently of the primary statement.
+ Fixed issue in CTE constructs where a recursive CTE that
referred to a SELECT that has duplicate column names, which are
typically deduplicated using labeling logic in 1.4, would fail
to refer to the deduplicated label name correctly within the
WITH clause.
+ Fixed regression where the tablesample() construct would fail to
be executable when constructed given a floating-point sampling
value not embedded within a SQL function.
* postgresql
+ Fixed issue in Insert.on_conflict_do_nothing() and
Insert.on_conflict_do_update() where the name of a unique
constraint passed as the constraint parameter would not be
properly truncated for length if it were based on a naming
convention that generated a too-long name for the PostgreSQL max
identifier length of 63 characters, in the same way which occurs
within a CREATE TABLE statement.
+ Fixed issue where the PostgreSQL ENUM datatype as embedded in
the ARRAY datatype would fail to emit correctly in create/drop
when the schema_translate_map feature were also in
use. Additionally repairs a related issue where the same
schema_translate_map feature would not work for the ENUM
datatype in combination with a CAST, that’s also intrinsic to
how the ARRAY(ENUM) combination works on the PostgreSQL dialect.
+ Fixed issue in Insert.on_conflict_do_nothing() and
Insert.on_conflict_do_update() where the name of a unique
constraint passed as the constraint parameter would not be
properly quoted if it contained characters which required
quoting.
* mssql
+ Fixed regression where the special dotted-schema name handling
for the SQL Server dialect would not function correctly if the
dotted schema name were used within the schema_translate_map
feature.
-------------------------------------------------------------------
Sun Jul 11 18:42:34 UTC 2021 - Antonio Larrosa <alarrosa@suse.com>