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

Upgrade to Django 2.2.9 #6494

Merged
merged 15 commits into from Feb 19, 2020
Merged

Upgrade to Django 2.2.9 #6494

merged 15 commits into from Feb 19, 2020

Conversation

humitos
Copy link
Member

@humitos humitos commented Dec 30, 2019

Group of changes are divided into commits:

  • update where to import resolve from
  • use on_delete=models.CASCADE to all those ForeignKey and OneToOneField in models and migrations files
  • remove view_ permissions manually created by us since they are automatically created since Django 2.1
  • upgrade django in requirements

NOTE: I tried using squashmigrations to avoid modifying migration files but it's way more complicated and since we are just forcing the default value to migrations, I do not think it's a problem

Closes #5058

humitos added 5 commits Dec 30, 2019
The on_delete argument for ForeignKey and OneToOneField is now
required in models and migrations. Consider squashing migrations so
that you have fewer of them to update.

https://docs.djangoproject.com/en/3.0/releases/2.0/#backwards-incompatible-changes-in-2-0
These permissions are created automatically by Django 2.x:

https://docs.djangoproject.com/en/2.2/ref/models/options/#default-permissions

The `view_` permission was added in 2.1. We were creating it manually
when using 1.11.
@humitos humitos requested a review from Dec 30, 2019
humitos added 5 commits Dec 30, 2019
To catch usage mistakes, the test Client and
django.utils.http.urlencode() now raise TypeError if None is passed as
a value to encode because None can’t be encoded in GET and POST
data. Either pass an empty string or omit the value.
Copy link
Member

@ericholscher ericholscher left a comment

Seems reasonable. Is there any specific testing we need to do on this locally to test it?

@humitos humitos added the Status: blocked label Jan 2, 2020
@humitos
Copy link
Member Author

@humitos humitos commented Jan 2, 2020

My main concern is about running the migrations (since they are modified) on a prod-like database. It should not be a problem because we are making the default value explicit only. However, that would be a good test.

Another thing to verify is that creating an environment from scratch (without any migration ran yet) it does work.

Locally, I did some QA and I didn't find anything strange/wrong.

On the other hand, I'm blocking this PR since we need to make the merge of other dependencies (-ext and corporate) together with this one. Aside from that, we can test this PR without problems in .org.

@stsewd
Copy link
Member

@stsewd stsewd commented Jan 6, 2020

use on_delete=models.CASCADE to all those ForeignKey and OneToOneField in models and migrations files

Was there a problem with just creating a new migration?

@humitos
Copy link
Member Author

@humitos humitos commented Jan 6, 2020

Was there a problem with just creating a new migration?

This is not possible because when running the old migrations file it will fail because there is no on_delete value. It's possible to squash them all, but it's a lot more work.

@davidfischer
Copy link
Contributor

@davidfischer davidfischer commented Jan 13, 2020

This is not possible because when running the old migrations file it will fail because there is no on_delete value.

I hadn't considered this. That's pretty unfortunate, but I think the way you did it is probably best.

Note: this is what the 1.9 release notes suggest as well.

Copy link
Contributor

@davidfischer davidfischer left a comment

I'm not sure about the redirects failures in CI but otherwise this looks good. I put this through the paces of running a full build through docker including verifying the output. It looked good and ran well!

My main concern is about running the migrations (since they are modified) on a prod-like database.

No migrations are "run" as part of this since you are just modifying past migrations. I did run the migrations from both my current database and from scratch just to be sure. It ran fine.

stsewd added 3 commits Feb 18, 2020
We are setting this view as handler404 on tests,
this view expects an extra arg (exception)

https://docs.djangoproject.com/en/2.2/ref/views/#the-404-page-not-found-view

(not sure why it worked before)
test_data.json contains references to eric.json
@stsewd
Copy link
Member

@stsewd stsewd commented Feb 18, 2020

I have update this PR with

  • Use newest version of django 2.2.x
  • Accept *args and **kwargs from the 404 view

We are setting this view as handler404 on tests,
this view expects an extra arg (exception)

https://docs.djangoproject.com/en/2.2/ref/views/#the-404-page-not-found-view

(not sure why it worked before)

  • Add the eric fixture to all tests using test_data, since test_data.json contains references to eric.json and django checks for integrity in sqlite.

@stsewd
Copy link
Member

@stsewd stsewd commented Feb 18, 2020

There are some migrations from django that we need to run

admin
 [X] 0001_initial
 [X] 0002_logentry_remove_auto_add
 [ ] 0003_logentry_add_action_flag_choices
auth
 [X] 0001_initial
 [X] 0002_alter_permission_name_max_length
 [X] 0003_alter_user_email_max_length
 [X] 0004_alter_user_username_opts
 [X] 0005_alter_user_last_login_null
 [X] 0006_require_contenttypes_0002
 [X] 0007_alter_validators_add_error_messages
 [X] 0008_alter_user_username_max_length
 [ ] 0009_alter_user_last_name_max_length
 [ ] 0010_alter_group_name_max_length
 [ ] 0011_update_proxy_permissions

stsewd
stsewd approved these changes Feb 18, 2020
Copy link
Member

@stsewd stsewd left a comment

I still want to test this a little more, but looks ok for now

@@ -151,7 +151,7 @@ class ServeDocs(SettingsOverrideObject):

class ServeError404Base(ServeRedirectMixin, ServeDocsMixin, View):

def get(self, request, proxito_path, template_name='404.html'):
def get(self, request, proxito_path, *args, template_name='404.html', **kwargs):
Copy link
Member Author

@humitos humitos Feb 19, 2020

Choose a reason for hiding this comment

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

I think this is not correct. The function definition is:

 defaults.page_not_found(request, exception, template_name='404.html')

There is no *args or **kwargs on it.

What we need to change instead is

def inner_view(request, *args, **kwargs):
return view_func(
request,
*args,
proxito_path=request.get_full_path(),
**kwargs,
)
return inner_view
if anything.

@stsewd
Copy link
Member

@stsewd stsewd commented Feb 19, 2020

I fixed this #6494 (comment) in a commit, but I push it when github was having problems, so it doesn't appear here...

@stsewd stsewd force-pushed the humitos/django-upgrade-2.2 branch from ce2e238 to 7b23d7a Compare Feb 19, 2020
@stsewd
Copy link
Member

@stsewd stsewd commented Feb 19, 2020

Had to force push the last commit to make it appear : D

@stsewd stsewd removed the Status: blocked label Feb 19, 2020
@ericholscher ericholscher merged commit 63ca0f9 into master Feb 19, 2020
3 checks passed
@ericholscher ericholscher deleted the humitos/django-upgrade-2.2 branch Feb 19, 2020
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.

4 participants