Поддержка МариаДБ¶

Django теперь официально поддерживает MariaDB 10.1 и выше. Дополнительную информацию см. в Заметках MariaDB.

Поддержка АСГИ¶

Django 3.0 начинает наш путь к полной асинхронности Django, обеспечивая поддержку работы в качестве приложения ASGI.

Это в дополнение к существующей поддержке WSGI. Django намерен поддерживать оба варианта в обозримом будущем. Однако функции асинхронности будут доступны только для приложений, работающих под управлением ASGI.

На этом этапе поддержка асинхронности применяется только к внешнему приложению ASGI. Внутри все остается синхронным. Асинхронное промежуточное ПО, представления и т. д. пока не поддерживаются. Однако вы можете использовать промежуточное программное обеспечение ASGI для приложения Django, что позволит вам комбинировать Django с другими платформами ASGI.

Нет необходимости переключать приложения, если вы не хотите начать экспериментировать с асинхронным кодом, но у нас есть документация по развертыванию с помощью ASGI, если вы хотите узнать больше.

Обратите внимание, что в качестве побочного эффекта этого изменения Django теперь знает об асинхронных циклах событий и будет блокировать вызов кода, помеченного как «асинхронно небезопасный», например операций ORM, из асинхронного контекста. Если вы раньше использовали Django из асинхронного кода, это может сработать, если вы делали это неправильно. Если вы видите ошибку SynchronousOnlyOperation, внимательно изучите свой код и переместите все операции с базой данных в синхронный дочерний поток.

Ограничения исключения в PostgreSQL¶

Новый класс ExclusionConstraint позволяет добавлять ограничения исключения в PostgreSQL. Ограничения добавляются в модели с помощью опции Meta.constraints.

Фильтровать выражения¶

Выражения, выводящие BooleanField, теперь можно использовать непосредственно в фильтрах QuerySet, без необходимости сначала аннотировать, а затем фильтровать по аннотации.

Перечисления для выбора полей модели¶

Пользовательские типы перечисления TextChoices, IntegerChoices и Choices теперь доступны как способ определения Field.choices. Типы TextChoices и IntegerChoices предусмотрены для текстовых и целочисленных полей. Класс Choices позволяет определить совместимое перечисление для других конкретных типов данных. Эти пользовательские типы перечислений поддерживают удобочитаемые метки, которые можно перевести и получить к ним доступ через свойство перечисления или его членов. См. Типы перечисления для получения более подробной информации и примеров.

Минорные изменения¶

Model.save() при указании значения по умолчанию для первичного ключа¶

Model.save() больше не пытается найти строку при сохранении нового экземпляра Model и предоставляется значение по умолчанию для первичного ключа, и всегда выполняет одиночный запрос INSERT. В старых версиях Django Model.save() выполнял либо INSERT, либо UPDATE в зависимости от того, существует строка или нет.

Это делает вызов Model.save() с предоставлением значения первичного ключа по умолчанию эквивалентным передаче force_insert=True в save() модели. Попытки использовать новый экземпляр Model для обновления существующей строки приведут к ошибке IntegrityError.

Чтобы обновить существующую модель для определенного значения первичного ключа, используйте вместо этого метод update_or_create() или QuerySet.filter(pk=…).update(…). Например:

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

Серверный API базы данных¶

В этом разделе описаны изменения, которые могут потребоваться в сторонних базах данных.

• Вторым аргументом DatabaseIntrospection.get_geometry_type() теперь является описание строки, а не имя столбца.

• DatabaseIntrospection.get_field_type() больше не может возвращать кортежи.

• Если база данных может создавать внешние ключи в том же операторе SQL, который добавляет поле, добавьте SchemaEditor.sql_create_column_inline_fk с соответствующим SQL; в противном случае установите DatabaseFeatures.can_create_inline_fk = False.

• DatabaseFeatures.can_return_id_from_insert и can_return_ids_from_bulk_insert переименованы в can_return_columns_from_insert и can_return_rows_from_bulk_insert.

• Функции базы данных теперь обрабатывают форматы datetime.timezone при создании с использованием экземпляров datetime.timedelta (например, timezone(timedelta(hours=5)), который будет выводить 'UTC+05:00'). Сторонние серверные программы должны обрабатывать этот формат при подготовке DateTimeField в datetime_cast_date_sql(), datetime_extract_sql() и т. д.

• Записи для AutoField, BigAutoField и SmallAutoField добавляются в DatabaseOperations.integer_field_ranges для поддержки валидаторов целочисленного диапазона для этих типов полей. Сторонним бэкэндам может потребоваться настроить записи по умолчанию.

• DatabaseOperations.fetch_returned_insert_id() заменяется на fetch_returned_insert_columns(), который возвращает список значений, возвращаемых оператором INSERT… RETURNING, вместо одного значения.

• DatabaseOperations.return_insert_id() заменяется на return_insert_columns(), который принимает аргумент fields, который представляет собой итерацию полей, возвращаемых после вставки. Обычно это только автоматически сгенерированный первичный ключ.

django.contrib.admin¶

• Сообщения об изменении истории модели администратора теперь предпочитают более читаемые метки полей вместо имен полей.

django.contrib.gis¶

• Поддержка PostGIS 2.1 удалена.

• Поддержка SpatiaLite 4.1 и 4.2 удалена.

• Поддержка GDAL 1.11 и GEOS 3.4 удалена.

Прекращена поддержка PostgreSQL 9.4.¶

Поддержка исходной версии PostgreSQL 9.4 заканчивается в декабре 2019 года. Django 3.0 поддерживает PostgreSQL 9.5 и выше.

Прекращена поддержка Oracle 12.1.¶

Восходящая поддержка Oracle 12.1 заканчивается в июле 2021 года. Django 2.2 будет поддерживаться до апреля 2022 года. Django 3.0 официально поддерживает Oracle 12.2 и 18c.

Удалены частные API совместимости с Python 2.¶

Хотя поддержка Python 2 была удалена в Django 2.0, некоторые частные API не были удалены из Django, чтобы сторонние приложения могли продолжать использовать их до окончания поддержки Python 2.

Поскольку мы ожидаем, что приложения потеряют совместимость с Python 2 при добавлении поддержки Django 3.0, в настоящее время мы удаляем эти API.

• django.test.utils.str_prefix() — строки не имеют префикса „u“ в Python 3.

• django.test.utils.patch_logger() — вместо этого используйте unittest.TestCase.assertLogs().

• django.utils.lru_cache.lru_cache() — псевдоним functools.lru_cache().

• django.utils.decorators.available_attrs() — эта функция возвращает functools.WRAPPER_ASSIGNMENTS.

• django.utils.decorators.ContextDecorator — псевдоним contextlib.ContextDecorator.

• django.utils._os.abspathu() — псевдоним os.path.abspath().

• django.utils._os.upath() и npath() — эти функции ничего не делают в Python 3.

• django.utils.six — удалите использование этой встроенной библиотеки или переключитесь на six.

• django.utils.encoding.python_2_unicode_совместимый() — псевдоним six.python_2_unicode_совместимый().

• django.utils.functional.curry() — используйте functools.partial() или functools.partialmethod. См. 5b1c389603a353625ae1603ba345147356336afb.

• django.utils.safestring.SafeBytes — не используется с Django 2.0.

Новое значение по умолчанию для параметра FILE_UPLOAD_PERMISSIONS.¶

В более старых версиях для параметра FILE_UPLOAD_PERMISSIONS по умолчанию установлено значение None. При настройке по умолчанию:FILE_UPLOAD_HANDLERS это приводит к тому, что загруженные файлы имеют разные разрешения в зависимости от их размера и используемого обработчика загрузки.

FILE_UPLOAD_PERMISSIONS теперь по умолчанию имеет значение 0o644, чтобы избежать этого несоответствия.

Новые значения по умолчанию для настроек безопасности¶

Чтобы сделать проекты Django более безопасными по умолчанию, некоторые настройки безопасности теперь имеют более безопасные значения по умолчанию:

• X_FRAME_OPTIONS теперь по умолчанию имеет значение 'DENY'.

• SECURE_CONTENT_TYPE_NOSNIFF теперь по умолчанию имеет значение True.

См. Что нового Раздел безопасности выше для получения более подробной информации об этих изменениях.

Разнообразный¶

• ContentType.__str__() теперь включает app_label модели для устранения неоднозначности моделей с одинаковым именем в разных приложениях.

• Поскольку доступ к языку в сеансе, а не в файле cookie, устарел, LocaleMiddleware больше не ищет язык пользователя в сеансе, а django.contrib.auth.logout() больше не сохраняет язык сеанса после выхода из системы.

• django.utils.html.escape() теперь использует html.escape() для экранирования HTML. Это преобразует ' в ' вместо предыдущего эквивалентного десятичного кода '.

• Опция django-admin test -k теперь работает как опция unittest -k, а не как ярлык для --keepdb.

• Поддержка pywatchman < 1.2.0 удалена.

• urlencode() теперь кодирует повторяемые значения такими, какие они есть при doseq=False, вместо того, чтобы повторять их, приводя их в соответствие с функцией стандартной библиотеки urllib.parse.urlencode().

• Фильтр шаблонов intword теперь переводит 1.0 как фразу в единственном числе, а все остальные числовые значения - как во множественном числе. Это может быть неправильно для некоторых языков.

• Присвоение значения атрибуту ForeignKey или OneToOneField '_id' модели теперь сбрасывает значение соответствующего поля. Последующий доступ к полю приведет к запросу.

• patch_vary_headers() теперь обрабатывает звездочку '*' в соответствии с RFC 7231 Section 7.1.4, т.е. если список имен полей заголовка содержит звездочку, то заголовок Vary будет состоять из одной звездочки '*'.

• В MySQL 8.0.16+ PositiveIntegerField и PositiveSmallIntegerField теперь включают проверочное ограничение для предотвращения отрицательных значений в базе данных.

• alias=None добавляется к подписи Expression.get_group_by_cols().

• RegexPattern, используемый re_path(), больше не возвращает аргументы ключевого слова со значениями None, которые должны быть переданы в представление для отсутствующих необязательных именованных групп.

django.utils.encoding.force_text() и smart_text()¶

Псевдонимы smart_text() и force_text() (начиная с Django 2.0) smart_str() и force_str() устарели. Игнорируйте это устаревание, если ваш код поддерживает Python 2, поскольку поведение smart_str() и force_str() там отличается.

Разнообразный¶

• django.utils.http.urlquote(), urlquote_plus(), urlunquote() и urlunquote_plus() устарели в пользу функций, псевдонимами которых они являются: urllib.parse.quote(), quote_plus(), unquote() и unquote_plus().

• django.utils.translation.ugettext(), ugettext_lazy(), ugettext_noop(), ungettext() и ungettext_lazy() устарели в пользу функций, для которых они являются псевдонимами: django.utils.translation.gettext(), gettext_lazy(), gettext_noop(), ngettext() и ngettext_lazy().

• Чтобы ограничить создание сеансов и, следовательно, отдать предпочтение некоторым стратегиям кэширования, django.views.i18n.set_language() прекратит установку языка пользователя в сеансе в Django 4.0. Начиная с Django 2.1, язык всегда хранится в файле cookie LANGUAGE_COOKIE_NAME.

• django.utils.text.unescape_entities() устарел в пользу html.unescape(). Обратите внимание, что в отличие от unescape_entities(), html.unescape() немедленно оценивает ленивые строки.

• Чтобы избежать возможной путаницы в отношении эффективной области действия, частная внутренняя утилита is_safe_url() переименована в url_has_allowed_host_and_scheme(). То, что URL-адрес имеет разрешенный хост и схему, в целом не означает, что он «безопасен». Например, оно может быть цитировано неправильно. Обязательно используйте iri_to_uri() в компоненте пути ненадежных URL-адресов.