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

Signature for various "operations" incompatible with Django >= 4.1 #171

Open
anentropic opened this issue Dec 11, 2024 · 1 comment
Open

Comments

@anentropic
Copy link

trying to use db functions like from django.db.models.functions Trunc fails due to change in signature in Django 4.1

Problem

I have a Django 5.1 project using Trunc

Trying to use django-redshift backend fails with:

        elif isinstance(self.output_field, DateField):
>           sql, params = connection.ops.date_trunc_sql(
                self.kind, sql, tuple(params), tzname
E               TypeError: DatabaseOperations.date_trunc_sql() takes from 3 to 4 positional arguments but 5 were given

.venv/lib/python3.11/site-packages/django/db/models/functions/datetime.py:271: TypeError

signature of date_trunc_sql and many other functions changed in Django 4.1, to add params arg https://github.com/django/django/blob/4.1/django/db/backends/base/operations.py#L113

making it incompatible with the Django 4.0 code in this project here:

def date_trunc_sql(self, lookup_type, field_name, tzname=None):

DATE_TRUNC itself is supported in Redshift https://docs.aws.amazon.com/redshift/latest/dg/r_DATE_TRUNC.html the problem is just in the Django layer

Expected results

Badges advertise support for Django 4.2, 5.0, 5.1

But I understand that compatibility with Django > 4.0 is tenuous due to needing to use Django 4.0 code, due to needing to use psycopg2 lib for connecting to Redshift, as psycopg3 has issues.

Environment info

  • OS: macOS 14.6.1
  • Python version: 3.11
  • Django version: 5.1
  • Django-Redshift-Backend version: latest
@shimizukawa
Copy link
Member

I see..., I hadn't considered that there would be an impact.
I'm sorry, but I don't have any short-term solutions at the moment. I think that advancing #167 is probably the most reliable solution.

I'm currently implementing an ad-hoc solution for supporting Django 4.2+, and I am aware that we need to re-implement it correctly.
Please refer to #167 for more information.

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

No branches or pull requests

2 participants