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.0/ below:

Django 3.0 release notes | Django documentation

Django 3.0 release notes

December 2, 2019

Welcome to Django 3.0!

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 2.2 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.0 supports Python 3.6, 3.7, 3.8, and 3.9 (as of 3.0.11). We highly recommend and only officially support the latest release of each series.

The Django 2.2.x series is the last to support Python 3.5.

Third-party library support for older version of Django

Following the release of Django 3.0, we suggest that third-party app authors drop support for all versions of Django prior to 2.2. At that time, you should be able to run your package’s tests using python -Wd so that deprecation warnings appear. After making the deprecation warning fixes, your app should be compatible with Django 3.0.

What’s new in Django 3.0 MariaDB support

Django now officially supports MariaDB 10.1 and higher. See MariaDB notes for more details.

ASGI support

Django 3.0 begins our journey to making Django fully async-capable by providing support for running as an ASGI application.

This is in addition to our existing WSGI support. Django intends to support both for the foreseeable future. Async features will only be available to applications that run under ASGI, however.

At this stage async support only applies to the outer ASGI application. Internally everything remains synchronous. Asynchronous middleware, views, etc. are not yet supported. You can, however, use ASGI middleware around Django’s application, allowing you to combine Django with other ASGI frameworks.

There is no need to switch your applications over unless you want to start experimenting with asynchronous code, but we have documentation on deploying with ASGI if you want to learn more.

Note that as a side-effect of this change, Django is now aware of asynchronous event loops and will block you calling code marked as “async unsafe” - such as ORM operations - from an asynchronous context. If you were using Django from async code before, this may trigger if you were doing it incorrectly. If you see a SynchronousOnlyOperation error, then closely examine your code and move any database operations to be in a synchronous child thread.

Exclusion constraints on PostgreSQL

The new ExclusionConstraint class enable adding exclusion constraints on PostgreSQL. Constraints are added to models using the Meta.constraints option.

Filter expressions

Expressions that output BooleanField may now be used directly in QuerySet filters, without having to first annotate and then filter against the annotation.

Enumerations for model field choices

Custom enumeration types TextChoices, IntegerChoices, and Choices are now available as a way to define Field.choices. TextChoices and IntegerChoices types are provided for text and integer fields. The Choices class allows defining a compatible enumeration for other concrete data types. These custom enumeration types support human-readable labels that can be translated and accessed via a property on the enumeration or its members. See Enumeration types for more details and examples.

Minor features django.contrib.admin django.contrib.auth django.contrib.gis django.contrib.postgres django.contrib.sessions django.contrib.syndication Cache File Storage Forms Internationalization Logging Management Commands Models Requests and Responses Security Tests Backwards incompatible changes in 3.0 Model.save() when providing a default for the primary key

Model.save() no longer attempts to find a row when saving a new Model instance and a default value for the primary key is provided, and always performs a single INSERT query. In older Django versions, Model.save() performed either an INSERT or an UPDATE based on whether or not the row exists.

This makes calling Model.save() while providing a default primary key value equivalent to passing force_insert=True to model’s save(). Attempts to use a new Model instance to update an existing row will result in an IntegrityError.

In order to update an existing model for a specific primary key value, use the update_or_create() method or QuerySet.filter(pk=…).update(…) instead. For example:

>>> MyModel.objects.update_or_create(pk=existing_pk, defaults={"name": "new name"})
>>> MyModel.objects.filter(pk=existing_pk).update(name="new name")
Database backend API

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

django.contrib.admin django.contrib.gis Dropped support for PostgreSQL 9.4

Upstream support for PostgreSQL 9.4 ends in December 2019. Django 3.0 supports PostgreSQL 9.5 and higher.

Dropped support for Oracle 12.1

Upstream support for Oracle 12.1 ends in July 2021. Django 2.2 will be supported until April 2022. Django 3.0 officially supports Oracle 12.2 and 18c.

Removed private Python 2 compatibility APIs

While Python 2 support was removed in Django 2.0, some private APIs weren’t removed from Django so that third party apps could continue using them until the Python 2 end-of-life.

Since we expect apps to drop Python 2 compatibility when adding support for Django 3.0, we’re removing these APIs at this time.

New default value for the FILE_UPLOAD_PERMISSIONS setting

In older versions, the FILE_UPLOAD_PERMISSIONS setting defaults to None. With the default FILE_UPLOAD_HANDLERS, this results in uploaded files having different permissions depending on their size and which upload handler is used.

FILE_UPLOAD_PERMISSIONS now defaults to 0o644 to avoid this inconsistency.

New default values for security settings

To make Django projects more secure by default, some security settings now have more secure default values:

See the What’s New Security section above for more details on these changes.

Miscellaneous Features deprecated in 3.0 django.utils.encoding.force_text() and smart_text()

The smart_text() and force_text() aliases (since Django 2.0) of smart_str() and force_str() are deprecated. Ignore this deprecation if your code supports Python 2 as the behavior of smart_str() and force_str() is different there.

Miscellaneous Features removed in 3.0

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

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

See Features deprecated in 2.1 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