Примечания к выпуску Django 3.0 ¶

Поддержка MariaDB ¶

Django теперь официально поддерживает MariaDB 10.1 и выше. См. Примечания MariaDB для получения более подробной информации.

Поддержка ASGI ¶

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- Отключите использование этой поставляемой библиотеки или переключитесь на шесть .
• django.utils.encoding.python_2_unicode_compatible()- Псевдоним six.python_2_unicode_compatible().
• django.utils.functional.curry()- Используйте functools.partial()или functools.partialmethod. См. 5b1c389603a353625ae1603 .
• 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для устранения неоднозначности моделей с одинаковыми именами в разных приложениях.
• Поскольку доступ к языку в сеансе, а не в LocaleMiddlewareфайле cookie устарел, он больше не ищет язык пользователя в сеансе и django.contrib.auth.logout()больше не сохраняет язык сеанса после выхода из системы.
• django.utils.html.escape()теперь используется html.escape()для экранирования HTML. Он преобразуется 'в 'вместо предыдущего эквивалентного десятичного кода '.
• Эта опция теперь работает как опция, а не как ярлык для .django-admin test -kunittest -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 язык всегда сохраняется в LANGUAGE_COOKIE_NAMEcookie.
• 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-адресов.