A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://docs.djangoproject.com/en/dev/releases/3.1/ below:

Django 3.1 release notes | Django documentation

Django 3.1 release notes

August 4, 2020

Welcome to Django 3.1!

These release notes cover the new features, as well as some backwards incompatible changes you’ll want to be aware of when upgrading from Django 3.0 or earlier. We’ve dropped some features that have reached the end of their deprecation cycle, and we’ve begun the deprecation process for some features.

See the How to upgrade Django to a newer version guide if you’re updating an existing project.

Python compatibility

Django 3.1 supports Python 3.6, 3.7, 3.8, and 3.9 (as of 3.1.3). We highly recommend and only officially support the latest release of each series.

What’s new in Django 3.1 Asynchronous views and middleware support

Django now supports a fully asynchronous request path, including:

To get started with async views, you need to declare a view using async def:

async def my_view(request):
    await asyncio.sleep(0.5)
    return HttpResponse("Hello, async world!")

All asynchronous features are supported whether you are running under WSGI or ASGI mode. However, there will be performance penalties using async code in WSGI mode. You can read more about the specifics in Asynchronous support documentation.

You are free to mix async and sync views, middleware, and tests as much as you want. Django will ensure that you always end up with the right execution context. We expect most projects will keep the majority of their views synchronous, and only have a select few running in async mode - but it is entirely your choice.

Django’s ORM, cache layer, and other pieces of code that do long-running network calls do not yet support async access. We expect to add support for them in upcoming releases. Async views are ideal, however, if you are doing a lot of API or HTTP calls inside your view, you can now natively do all those HTTP calls in parallel to considerably speed up your view’s execution.

Asynchronous support should be entirely backwards-compatible and we have tried to ensure that it has no speed regressions for your existing, synchronous code. It should have no noticeable effect on any existing Django projects.

JSONField for all supported database backends

Django now includes models.JSONField and forms.JSONField that can be used on all supported database backends. Both fields support the use of custom JSON encoders and decoders. The model field supports the introspection, lookups, and transforms that were previously PostgreSQL-only:

from django.db import models


class ContactInfo(models.Model):
    data = models.JSONField()


ContactInfo.objects.create(
    data={
        "name": "John",
        "cities": ["London", "Cambridge"],
        "pets": {"dogs": ["Rufus", "Meg"]},
    }
)
ContactInfo.objects.filter(
    data__name="John",
    data__pets__has_key="dogs",
    data__cities__contains="London",
).delete()

If your project uses django.contrib.postgres.fields.JSONField, plus the related form field and transforms, you should adjust to use the new fields, and generate and apply a database migration. For now, the old fields and transforms are left as a reference to the new ones and are deprecated as of this release.

DEFAULT_HASHING_ALGORITHM settings

The new DEFAULT_HASHING_ALGORITHM transitional setting allows specifying the default hashing algorithm to use for encoding cookies, password reset tokens in the admin site, user sessions, and signatures created by django.core.signing.Signer and django.core.signing.dumps().

Support for SHA-256 was added in Django 3.1. If you are upgrading multiple instances of the same project to Django 3.1, you should set DEFAULT_HASHING_ALGORITHM to 'sha1' during the transition, in order to allow compatibility with the older versions of Django. Note that this requires Django 3.1.1+. Once the transition to 3.1 is complete you can stop overriding DEFAULT_HASHING_ALGORITHM.

This setting is deprecated as of this release, because support for tokens, cookies, sessions, and signatures that use SHA-1 algorithm will be removed in Django 4.0.

Minor features django.contrib.admin django.contrib.auth django.contrib.contenttypes django.contrib.gis django.contrib.humanize django.contrib.postgres django.contrib.sessions django.contrib.staticfiles Cache CSRF Email Error Reporting File Storage Forms Internationalization Management Commands Models Pagination Requests and Responses Security Templates Tests URLs Utilities Miscellaneous Backwards incompatible changes in 3.1 Database backend API

This section describes changes that may be needed in third-party database backends.

Dropped support for MariaDB 10.1

Upstream support for MariaDB 10.1 ends in October 2020. Django 3.1 supports MariaDB 10.2 and higher.

contrib.admin browser support

The admin no longer supports the legacy Internet Explorer browser. See the admin FAQ for details on supported browsers.

AbstractUser.first_name max_length increased to 150

A migration for django.contrib.auth.models.User.first_name is included. If you have a custom user model inheriting from AbstractUser, you’ll need to generate and apply a database migration for your user model.

If you want to preserve the 30 character limit for first names, use a custom form:

from django import forms
from django.contrib.auth.forms import UserChangeForm


class MyUserChangeForm(UserChangeForm):
    first_name = forms.CharField(max_length=30, required=False)

If you wish to keep this restriction in the admin when editing users, set UserAdmin.form to use this form:

from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.models import User


class MyUserAdmin(UserAdmin):
    form = MyUserChangeForm


admin.site.unregister(User)
admin.site.register(User, MyUserAdmin)
Miscellaneous Features deprecated in 3.1 PostgreSQL JSONField

django.contrib.postgres.fields.JSONField and django.contrib.postgres.forms.JSONField are deprecated in favor of models.JSONField and forms.JSONField.

The undocumented django.contrib.postgres.fields.jsonb.KeyTransform and django.contrib.postgres.fields.jsonb.KeyTextTransform are also deprecated in favor of the transforms in django.db.models.fields.json.

The new JSONFields, KeyTransform, and KeyTextTransform can be used on all supported database backends.

Miscellaneous Features removed in 3.1

These features have reached the end of their deprecation cycle and are removed in Django 3.1.

See Features deprecated in 2.2 for details on these changes, including how to remove usage of these features.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.3