[Django] #31714: ResolvedOuterRef object has no get_lookup
Django
-------------------------------------+-------------------------------------
Reporter: BorisZZZ | Owner: nobody
Type: Bug | Status: new
Component: Database | Version: 3.0
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
This looks like an issue very similar to #28621, only in this case the
issue is cause by using the annotation on the LHS of a filter.
For example,
{{{
class A(models.Model):
r = IntegerRangeField()
A.objects.annotate(x=OuterRef("x")).filter(x__contained_in=F("r"))
}}}
will result in the following stack trace:
{{{
Traceback (most recent call last):
...
File "/usr/local/lib/python3.8/site-packages/django/db/models/query.py",
line 904, in filter
return self._filter_or_exclude(False, *args, **kwargs)
File "/usr/local/lib/python3.8/site-packages/django/db/models/query.py",
line 923, in _filter_or_exclude
clone.query.add_q(Q(*args, **kwargs))
File "/usr/local/lib/python3.8/site-
packages/django/db/models/sql/query.py", line 1350, in add_q
clause, _ = self._add_q(q_object, self.used_aliases)
File "/usr/local/lib/python3.8/site-
packages/django/db/models/sql/query.py", line 1377, in _add_q
child_clause, needed_inner = self.build_filter(
File "/usr/local/lib/python3.8/site-
packages/django/db/models/sql/query.py", line 1267, in build_filter
condition = self.build_lookup(lookups, reffed_expression, value)
File "/usr/local/lib/python3.8/site-
packages/django/db/models/sql/query.py", line 1153, in build_lookup
lookup_class = lhs.get_lookup(lookup_name)
AttributeError: 'ResolvedOuterRef' object has no attribute 'get_lookup'
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31714>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Reporter: BorisZZZ | Owner: nobody
Cleanup/optimization |
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Bug => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
I think we could error out which a more appropriate message but it will be
very hard to make the above queryset work since `OuterRef` cannot be
resolved to a proper `output_field` until its queryset gets annotated to
an outer query. I guess we could allow an `output_field` to be specified
on `OuterRef` initialization to allow `filter` to reference it before it's
resolved to a `Col`.
--
Ticket URL: <https://code.djangoproject.com/ticket/31714#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: BorisZZZ | Owner: nobody
Cleanup/optimization |
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Denis Verbin (added)
Comment:
I'm faced with the same issue (#32043) and hope it will be fixed.
--
Ticket URL: <https://code.djangoproject.com/ticket/31714#comment:2>
Django
-------------------------------------+-------------------------------------
Type: | Barber
Cleanup/optimization | Status: assigned
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Phil-Barber
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/31714#comment:3>
Django
-------------------------------------+-------------------------------------
Type: | Barber
Cleanup/optimization | Status: assigned
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mariusz Felisiak):
As a workaround `OuterRef` can be wrapped in `ExpressionWrapper`, e.g.
{{{#!python
A.objects.annotate(
x=ExpressionWrapper(OuterRef("x"), output_field=IntegerRangeField())
).filter(x__contained_in=F("r"))
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31714#comment:4>
Django
-------------------------------------+-------------------------------------
Type: | Barber
Cleanup/optimization | Status: assigned
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Mariusz Felisiak):
`filtered_relation.tests.FilteredRelationTests.test_conditional_expression_with_subquery`
should work when this ticket is fixed:
{{{#!python
def test_conditional_expression_with_subquery(self):
self.assertSequenceEqual(
Author.objects.annotate(
book_editor=FilteredRelation(
"book__editor",
condition=Q(Exists(
Editor.objects.annotate(
author_name=OuterRef('name'),
).filter(
author_name__istartswith=F('name'),
)
)),
),
),
[self.author1],
)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/31714#comment:5>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: Phil-Barber => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/31714#comment:6>
Django
-------------------------------------+-------------------------------------
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 3.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
FWIW I [https://forum.djangoproject.com/t/error-when-annotating-distance-
between-2-points-inside-a-subquery-geodjango/30879 stumbled upon another
user running into the same problem] but for `_output_field_or_none`.
I think that an appropriate solution here could be to
1. Allow an `output_field` to be specified to `OuterRef` and percolate to
`ResolvedOuterRef`. It's a common pattern for `Expression`-like to accept
this kind of parameter.
2. At the time `ResolvedOuterRef` performs its final resolution in the
outer query error out if there is a mismatch of `output_field` (type only
should be enough) between what was explicitly specified and the resolved
expression one.
While the `ExpressionWrapper` solution works I think
[https://forum.djangoproject.com/t/error-when-annotating-distance-
between-2-points-inside-a-subquery-geodjango/30879/4 it's a big leap] for
users to figure out they should be using it when they encounter a
seemingly random `AttributeError`.
--
Ticket URL: <https://code.djangoproject.com/ticket/31714#comment:7>