-
Notifications
You must be signed in to change notification settings - Fork 28
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
Conversation
@@ -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. |
There was a problem hiding this comment.
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.*)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
django_spanner/schema.py
Outdated
self.deferred_sql.append( | ||
self._create_unique_sql(model, [field.column]) | ||
) | ||
if USING_DJANGO_3: |
There was a problem hiding this comment.
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?
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 Thank you for all of your work on this. It means a lot. 😄 |
No description provided.