Do not pass with_col_aliases=True to CTE compiler
#81
Conversation
Django 4.2 began passing this argument, which broke CTE queries because columns could not be referenced via `<cte>.col.<column_name>` syntax after the compiler added aliases. This change makes all django-cte tests pass on Django 4.2, but it is unclear what other effects it may have.
- Add new Django versions, remove old - Remove Python 3.7, which is EOL
Fix regression in Django 4.2 without undoing the fix for UNION with ORDER BY and select_related.
...in CTE with window function that triggers Django's auto-aliasing.
There was a problem hiding this comment.
This change makes all django-cte tests pass on Django 4.2, but it is unclear what other effects it may have.
Could you update the description of this PR to explain the rationale behind these changes? I think you have a better understanding of what effects this change may have now than you did when this PR was first created.
Should there be a note about this in any documentation as well? Or do you plan to do that in a separate PR?
|
Description updated.
Yes, I plan to make a note about this in the change log when it gets released. |
|
Just migrated my project from Django-4.1.13 to Django-4.2.7 and tested with the current main branch. I can confirm that CTE-queries now work as expected. |
Django 4.2 began passing this argument, which broke CTE queries because columns could not be referenced via
<cte>.col.<column_name>syntax after the compiler added aliases. This change makes all django-cte tests pass on Django 4.2.As demonstrated in test_heterogeneous_filter_in_cte, it is possible to create CTEs with window functions that produce mal-formed SQL due to compiler-added aliases. The same is true with
UNIONqueries that useORDER BYandselect_related. Making those queries work probably requires a change to Django ORM internals.Workaround for #66.