]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
improve detection / errors for unknown hashability w/ unique
authorMike Bayer <mike_mp@zzzcomputing.com>
Wed, 11 Oct 2023 22:06:17 +0000 (18:06 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Thu, 12 Oct 2023 14:58:00 +0000 (10:58 -0400)
commit1f388a199ecbce596382b7a5d52c67a785503dd8
treed0afaafe05b18c6eb43bf0ef11ca2214f7d13404
parenta342b3d503f968bbf43f3b2de1f4f623b03a6310
improve detection / errors for unknown hashability w/ unique

Fixed issue where calling :meth:`_engine.Result.unique` with a new-style
:func:`.select` query in the ORM, where one or more columns yields values
that are of "unknown hashability", typically when using JSON functions like
``func.json_build_object()`` without providing a type, would fail
internally when the returned values were not actually hashable. The
behavior is repaired to test the objects as they are received for
hashability in this case, raising an informative error message if not. Note
that for values of "known unhashability", such as when the :class:`.JSON`
or :class:`.ARRAY` types are used directly, an informative error message
was already raised.

The "hashabiltiy testing" fix here is applied to legacy :class:`.Query` as
well, however in the legacy case, :meth:`_engine.Result.unique` is used for
nearly all queries, so no new warning is emitted here; the legacy behavior
of falling back to using ``id()`` in this case is maintained, with the
improvement that an unknown type that turns out to be hashable will now be
uniqufied, whereas previously it would not.

Fixes: #10459
Change-Id: I7317d7ee10c129fc1ab3beeb17c66f34eb063d17
doc/build/changelog/unreleased_20/10459.rst [new file with mode: 0644]
lib/sqlalchemy/orm/loading.py
test/orm/test_query.py