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

Changes for Django 4.2. This PR is not for review as it is just used for testing the ongoing changes #860

Closed
wants to merge 24 commits into from

Conversation

ankiaga
Copy link
Contributor

@ankiaga ankiaga commented Mar 11, 2024

No description provided.

@product-auto-label product-auto-label bot added the api: spanner Issues related to the googleapis/python-spanner-django API. label Mar 11, 2024
@ankiaga ankiaga marked this pull request as draft March 11, 2024 09:23
@@ -46,7 +46,7 @@
USE_EMULATOR = os.getenv("SPANNER_EMULATOR_HOST") is not None

# Only active LTS django versions (2.2.*, 3.2.*) are supported by this library right now.
Copy link

Choose a reason for hiding this comment

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

nit: (2.2., 3.2., 4.2.*)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the comments but this is just a draft PR that I am using for testing for Django 4.2 so its just a hack to test it and not ready for review.

Copy link

Choose a reason for hiding this comment

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

Thank you @ankiaga , if the effort to support 5.0 is not a lot on top of 4.2, can we also add support to 5.0?
This will allow spanner users to upgrade to django 5.0, everybody is on 3.2 currently, I prefer migrate from 3.2->5.0 in one go, instead of 3.2 -> 4.2 -> then in 2 years -> 5.2

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are first planning to release 4.2 and then we will take a call for supporting 5.0 as well but we are already discussing this internally

Copy link

Choose a reason for hiding this comment

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

With this release, could it at least be possible to override the version check? I'm fairly certain these changes will work for 5.

Copy link

Choose a reason for hiding this comment

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

+1 to @grjones , if we don't officially support 5.0, maybe allow users to bypass the check and take our own risk

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Please note that these are not complete changes for Django 4.2 and I am fixing them as I am finding more issues.

Also to release 5.0 (similar to 4.2) we need to make sure that all the system tests from Django core repo works whose number is in tens of thousands. This is the main challenge to release a new version. Currently many hundreds of tests are failing as I am trying to migrate to 4.2 and root causing and fixing them takes a lot of time

@@ -31,7 +31,7 @@


USING_DJANGO_3 = False
if django.VERSION[:2] == (3, 2):
if django.VERSION[:2] == (3, 2) or django.VERSION[:2] == (4, 2):
USING_DJANGO_3 = True
Copy link

@jaz-la jaz-la Mar 14, 2024

Choose a reason for hiding this comment

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

if the change required to also support 5.0 is minimum, maybe just check if django version is >=3.2 and <= 5.0, and thrown an exception otherwise?
This will drop the support of 2.2, and then there is no need to keep USING_DJANGO_3

Copy link

Choose a reason for hiding this comment

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

also USING_DJANGO_3 is semantically wrong once 4.2 is supported.

self.deferred_sql.append(
self._create_unique_sql(model, [field.column])
)
if USING_DJANGO_3:
Copy link

Choose a reason for hiding this comment

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

with django 3, originally it calls self._create_unique_sql(model, [field.column]) and now it calls self._create_unique_sql(model, [field]) is it actually right?

@jaz-la
Copy link

jaz-la commented Mar 14, 2024

given that the change is small, can we support django 5.0, and drop the support for 2.2? In this case, the USING_DJANGO_3 can also be removed?

@ankiaga ankiaga changed the title Changes for Django 4.2 Changes for Django 4.2. This PR is not for review as it is just used for testing the ongoing changes Mar 22, 2024
@grjones
Copy link

grjones commented Apr 11, 2024

@ankiaga Thank you for all of your work on this. It means a lot. 😄

@ankiaga ankiaga closed this Apr 12, 2024
@ankiaga ankiaga deleted the django-4.2 branch April 12, 2024 04:57
@jaz-la jaz-la mentioned this pull request Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: spanner Issues related to the googleapis/python-spanner-django API.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants