#34963: Recursive and other "combinator" queries broken in django-cte
-------------------------------+--------------------------------------
Reporter: Daniel Miller | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 4.2
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------------------------
Comment (by Daniel Miller):
Hi Natalia, thanks for your prompt response.
I could have done a better job explaining why I think this is a bug in
Django. As of
[https://code.djangoproject.com/changeset/70499b25c708557fb9ee2264686cd172f4b2354e
70499b2] all "combinator" queries (queries using `UNION`, etc.) now have
compiler-generated aliases `col1`, `col2`, ... applied to unaliased^1^
columns. This change was made to support a small subset of queries that
use a combinator with `ORDER BY` and `select_related`. However, the fix as
implemented also unnecessarily affects all other combinator queries as
well. Frankly I am surprised that it did not break anything else outside
of django-cte. Is there a way to implement a fix so that it only affects
queries where aliases are needed?
In my attempts to fix the issue in django-cte I have been unable to find a
way to cleanly disable compiler-level aliasing just for CTE queries where
it breaks the ability to reference columns by name. One reason is that
many ORM methods like `get_combinator_sql` are large and overriding them
is difficult or impossible to do in a maintainable way. I am open to
suggestions for how to accomplish this within django-cte if there is a
good way to do that.
I think it is in Django's interest to make it possible for projects like
django-cte to extend the functionality of the ORM with new features, since
the alternative is to have all such features implemented internally and
maintained as part of Django or have them be repeatedly broken as Django
evolves over time.
^1^ The definition of "unaliased" here is a bit murky. There are at least
two ways a column can be aliased: explicitly at the Query level, or
implicitly at the Compiler level when `with_col_aliases=True`. Compiler-
level aliases do not mask or override Query-level aliases. My
understanding of "unaliased" is all columns without a Query-level alias.
--
Ticket URL: <https://code.djangoproject.com/ticket/34963#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018bba64afb1-324adf41-0e73-40e9-acd6-e80f3fc5faa7-000000%40eu-central-1.amazonses.com.
