]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
Apply new uniquing rules for future ORM selects
authorMike Bayer <mike_mp@zzzcomputing.com>
Wed, 21 Jul 2021 19:44:27 +0000 (15:44 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Wed, 21 Jul 2021 22:02:02 +0000 (18:02 -0400)
commit8822d832679cdc13bb631dd221d0f5932f6540c7
tree1d91be9f3c6843df368bb89cfa894d9678a14ce1
parent54ca40b8b3e4286183b64198573b55731b1ce363
Apply new uniquing rules for future ORM selects

Fixed issue where usage of the :meth:`_result.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 :meth:`_result.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 :class:`_orm.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.

Fixes: #6769
Change-Id: I5747f706f1e97c78867b5cf28c73360497273808
doc/build/changelog/unreleased_14/6769.rst [new file with mode: 0644]
lib/sqlalchemy/orm/context.py
lib/sqlalchemy/orm/loading.py
lib/sqlalchemy/orm/query.py
lib/sqlalchemy/sql/sqltypes.py
test/orm/test_query.py