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/4.2/ below:

Django 4.2 release notes | Django documentation

Django 4.2 release notes

April 3, 2023

Welcome to Django 4.2!

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 4.1 or earlier. 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.

Django 4.2 is designated as a long-term support release. It will receive security updates for at least three years after its release. Support for the previous LTS, Django 3.2, will end in April 2024.

Python compatibility

Django 4.2 supports Python 3.8, 3.9, 3.10, 3.11, and 3.12 (as of 4.2.8). We highly recommend and only officially support the latest release of each series.

What’s new in Django 4.2 Psycopg 3 support

Django now supports psycopg version 3.1.8 or higher. To update your code, install the psycopg library, you don’t need to change the ENGINE as django.db.backends.postgresql supports both libraries.

Support for psycopg2 is likely to be deprecated and removed at some point in the future.

Be aware that psycopg 3 introduces some breaking changes over psycopg2. As a consequence, you may need to make some changes to account for differences from psycopg2.

Comments on columns and tables

The new Field.db_comment and Meta.db_table_comment options allow creating comments on columns and tables, respectively. For example:

from django.db import models


class Question(models.Model):
    text = models.TextField(db_comment="Poll question")
    pub_date = models.DateTimeField(
        db_comment="Date and time when the question was published",
    )

    class Meta:
        db_table_comment = "Poll questions"


class Answer(models.Model):
    question = models.ForeignKey(
        Question,
        on_delete=models.CASCADE,
        db_comment="Reference to a question",
    )
    answer = models.TextField(db_comment="Question answer")

    class Meta:
        db_table_comment = "Question answers"

Also, the new AlterModelTableComment operation allows changing table comments defined in the Meta.db_table_comment.

Mitigation for the BREACH attack

GZipMiddleware now includes a mitigation for the BREACH attack. It will add up to 100 random bytes to gzip responses to make BREACH attacks harder. Read more about the mitigation technique in the Heal The Breach (HTB) paper.

In-memory file storage

The new django.core.files.storage.InMemoryStorage class provides a non-persistent storage useful for speeding up tests by avoiding disk access.

Custom file storages

The new STORAGES setting allows configuring multiple custom file storage backends. It also controls storage engines for managing files (the "default" key) and static files (the "staticfiles" key).

The old DEFAULT_FILE_STORAGE and STATICFILES_STORAGE settings are deprecated as of this release.

Minor features django.contrib.admin django.contrib.auth django.contrib.gis django.contrib.postgres django.contrib.sitemaps django.contrib.staticfiles Database backends Error Reporting Forms Internationalization Logging Management Commands Migrations Models Requests and Responses Tests Utilities Validators Backwards incompatible changes in 4.2 Database backend API

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

Dropped support for MariaDB 10.3

Upstream support for MariaDB 10.3 ends in May 2023. Django 4.2 supports MariaDB 10.4 and higher.

Dropped support for MySQL 5.7

Upstream support for MySQL 5.7 ends in October 2023. Django 4.2 supports MySQL 8 and higher.

Dropped support for PostgreSQL 11

Upstream support for PostgreSQL 11 ends in November 2023. Django 4.2 supports PostgreSQL 12 and higher.

Setting update_fields in Model.save() may now be required

In order to avoid updating unnecessary columns, QuerySet.update_or_create() now passes update_fields to the Model.save() calls. As a consequence, any fields modified in the custom save() methods should be added to the update_fields keyword argument before calling super(). See Overriding predefined model methods for more details.

Dropped support for raw aggregations on MySQL

MySQL 8+ allows functional dependencies on GROUP BY columns, so the pre-Django 4.2 workaround of grouping by primary keys of the main table is removed. As a consequence, using RawSQL() aggregations is no longer supported on MySQL as there is no way to determine if such aggregations are needed or valid in the GROUP BY clause. Use Aggregation functions instead.

Miscellaneous Features deprecated in 4.2 index_together option is deprecated in favor of indexes

The Meta.index_together option is deprecated in favor of the indexes option.

Migrating existing index_together should be handled as a migration. For example:

class Author(models.Model):
    rank = models.IntegerField()
    name = models.CharField(max_length=30)

    class Meta:
        index_together = [["rank", "name"]]

Should become:

class Author(models.Model):
    rank = models.IntegerField()
    name = models.CharField(max_length=30)

    class Meta:
        indexes = [models.Index(fields=["rank", "name"])]

Running the makemigrations command will generate a migration containing a RenameIndex operation which will rename the existing index. Next, consider squashing migrations to remove index_together from historical migrations.

The AlterIndexTogether migration operation is now officially supported only for pre-Django 4.2 migration files. For backward compatibility reasons, it’s still part of the public API, and there’s no plan to deprecate or remove it, but it should not be used for new migrations. Use AddIndex and RemoveIndex operations instead.

Passing encoded JSON string literals to JSONField is deprecated

JSONField and its associated lookups and aggregates used to allow passing JSON encoded string literals which caused ambiguity on whether string literals were already encoded from database backend’s perspective.

During the deprecation period string literals will be attempted to be JSON decoded and a warning will be emitted on success that points at passing non-encoded forms instead.

Code that used to pass JSON encoded string literals:

Document.objects.bulk_create(
    Document(data=Value("null")),
    Document(data=Value("[]")),
    Document(data=Value('"foo-bar"')),
)
Document.objects.annotate(
    JSONBAgg("field", default=Value("[]")),
)

Should become:

Document.objects.bulk_create(
    Document(data=Value(None, JSONField())),
    Document(data=[]),
    Document(data="foo-bar"),
)
Document.objects.annotate(
    JSONBAgg("field", default=[]),
)

From Django 5.1+ string literals will be implicitly interpreted as JSON string literals.

Miscellaneous

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