Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix dj42 issues 66 #78

Closed
wants to merge 2 commits into from
Closed

Conversation

pgammans
Copy link
Contributor

This add support for Django 4.2 to pass the current test.

In Django 4.2 the SQL of a CTE is build but the columns are automatically asigned an alias this cases the CTE references to fail. This commit attempts to choose beter column aliases so they match the CTE names.
ie Unlike Django using col1, col2 for un-aliased columns we use the same as the field name.

Whist this passes the test it is a invasive set of changes, i did think i'd manages a ultra simple set of changes

The test added is to ensure we don't break the column renaming fix in django 4.2. As the simple removal with_col_aliases in #66 (comment) does to make django_cte pass it test

Fixes: #66

unlike Django using col1, col2 for un-aliased columns we use the same as
the field name, this fixes a regression in Django 4.2 which causes the
cte columns to to match the table names
@adamanthil
Copy link

Our team is waiting on this change to update to Django 4.2. Posting to watch. What is required to get this merged?

@millerdev
Copy link
Contributor

As noted in the PR description, this is an invasive set of changes. I have not had time to review it in depth, but I can say that I plan to have a version of django-cte that supports Django 4.2 before 3.2 EOL (April 2024).

@millerdev
Copy link
Contributor

millerdev commented Nov 7, 2023

Unlike Django using col1, col2 for un-aliased columns we use the same as the field name

How is the outcome of this PR different from the solution mentioned in #66 (comment)? That is, if CTE fields are aliased using the same name as the field name, how is that different from overriding and passing with_col_aliases=False to the CTE query compiler?

If they are functionally the same, then I think I would prefer to override and pass with_col_aliases=False since that is a less invasive solution, although I think it may be incomplete.

One thing I am unclear on is whether with_col_aliases=False causes column aliases set at the query level (outside of the compiler) to be stripped? If it does, then I can see how that would be problematic.

if query.combinator:
return as_sql()

ctes = []
params = []
if django.VERSION > (4, 2):
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

>= would be less misleading. While the actual VERSION tuple for 4.2 looks like (4, 2, 0, 'final', 0), a human reader might assume this is intended to exclude 4.2.

(Same on line 162.)

@coltonpark5
Copy link

As noted in the PR description, this is an invasive set of changes. I have not had time to review it in depth, but I can say that I plan to have a version of django-cte that supports Django 4.2 before 3.2 EOL (April 2024).

@millerdev With 3.2 now EOL. Just curious to know if you have an idea of the timeline to support 4.2?

@millerdev
Copy link
Contributor

@coltonpark5 Except for a few edge cases, #66 is fixed by #81, which was released in v1.3.2. I also reported a bug in Django, but it seems the dev team is not able to maintain compatibility with projects like django-cte that depend on ORM internals.

A better solution may be possible if proper ORDER BY $index support were implemented for a future version of Django, but in the mean time queries will need to be adjusted to make them work with Django 4.2.

I'm going to close this PR since #81 was the preferred fix.

@millerdev millerdev closed this Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

“no such column”/“column does not exist” errors in Django 4.2
5 participants