Django 3.2 Upgrade: Key Changes

Owned by Jeremy Bowman (Deactivated)
Last updated: Dec 12, 2023 by Feanil Patel
3 min read

The following are the changes introduced in Django 3.0 through 3.2 which seem most likely to impact Open edX developers once the upgrade from Django 2.2 to 3.2 is complete. Many more minor changes can be found in the changelogs for Django 3.0, 3.1, and 3.2. Some of these will be very useful for specific pieces of code, but probably aren’t of general interest to most Open edX developers; developers who can spare the time are encouraged to skim the changelogs at their convenience to see if there’s anything particularly useful for their work (or that they feel merits addition to the list of highlights below).

  • The biggest addition in Django 3.2 over 2.2 is support for ASGI (Asynchronous Server Gateway Interface). While there isn’t a pressing need for this in Open edX, we should start thinking about where we could use it to more efficiently utilize our server resources in order to reduce costs. This is currently most useful for views that perform multiple network requests. [Changelog entry]

  • Cache operations were updated to no longer treat None the same as a cache miss, but the python-memcached library we currently use doesn’t support this and is being deprecated; we’ll want to switch to one of two alternatives. [Changelog entry]

  • JSONField is now available for MySQL; we’ve been using a 3rd-party package for similar functionality, which we may be able to stop using after this upgrade. [Changelog entry]

  • The once-ubiquitous django.shortcuts.render_to_response() has been removed in favor of django.shortcuts.render() (which requires the request as an additional parameter). [Changelog entry]

  • All subclasses of Django’s test classes now have a debug() method which doesn’t catch exceptions, making it easier to find problems with a test using a debugger. See https://code.djangoproject.com/ticket/27391 for more details. [Changelog entry]

  • There is no longer a need to specify default_app_config in Django apps with only one AppConfig subclass, and putting the full dotted path to the AppConfig class in the project’s settings is no longer recommended (but still allowed). [Changelog entry]

  • Class attributes assigned during TestCase.setUpTestData() are now isolated for each test method, making it easier to use this test performance enhancement without needing to take care to avoid mutating such attributes. [Changelog entry]

  • There are a few new options for enumeration fields, including support for translations on text choices. [Changelog entry]

  • There is now a DEFAULT_AUTO_FIELD setting to default implicit primary keys to big integers instead of regular integers; this will become the default behavior in future versions of Django to reduce the frequency of hitting database limits for the sake of minuscule storage and performance savings. [Changelog entry]

  • There is now support for themes in Django Admin, and a dark theme is included. [Changelog entry]

  • The Django Admin UI has dropped support for Internet Explorer. [Changelog entry]

Changes Important to Upgrading

The following changes are important to be aware of when upgrading a library or service from Django 2.2 to 3.2, but not so much once the upgrade is complete. Again, this isn’t a comprehensive list (see the Django release notes for that), just the issues most commonly encountered when upgrading Open edX repositories.

  • Hashes for cookies and sessions switched from SHA-1 to SHA-256. To keep multiple server instances able to read each other’s data during the upgrade deployment, IDAs should set the DEFAULT_HASHING_ALGORITHM setting to “sha1”. Once the deployment is complete and we’re confident a rollback won’t be needed, this setting can then be removed again. [Changelog entry]

  • DEFAULT_AUTO_FIELD should probably be set to “django.db.models.AutoField“ for most repositories to streamline the upgrade, but after upgrading it is recommended to explicitly migrate or declare existing implicit ID fields so this setting can be removed and BigAutoField can be used for new ID fields.