diff options
| author | Mike Bayer <mike_mp@zzzcomputing.com> | 2021-07-21 15:44:27 -0400 |
|---|---|---|
| committer | Mike Bayer <mike_mp@zzzcomputing.com> | 2021-07-21 18:02:02 -0400 |
| commit | 8822d832679cdc13bb631dd221d0f5932f6540c7 (patch) | |
| tree | 1d91be9f3c6843df368bb89cfa894d9678a14ce1 /lib/sqlalchemy/sql | |
| parent | 54ca40b8b3e4286183b64198573b55731b1ce363 (diff) | |
| download | sqlalchemy-8822d832679cdc13bb631dd221d0f5932f6540c7.tar.gz | |
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
Diffstat (limited to 'lib/sqlalchemy/sql')
| -rw-r--r-- | lib/sqlalchemy/sql/sqltypes.py | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/lib/sqlalchemy/sql/sqltypes.py b/lib/sqlalchemy/sql/sqltypes.py index 1b05465c9..44431d38f 100644 --- a/lib/sqlalchemy/sql/sqltypes.py +++ b/lib/sqlalchemy/sql/sqltypes.py @@ -3184,8 +3184,6 @@ class NullType(TypeEngine): _isnull = True - hashable = False - def literal_processor(self, dialect): def process(value): raise exc.CompileError( |