Примечания к выпуску 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() т.д.
• Строки добавляются DatabaseOperations.integer_field_ranges для полей AutoField , BigAutoField а также в SmallAutoField целях поддержки валидаторов диапазона целых чисел для этих типов полей. Сторонним движкам, возможно, придется адаптировать строки по умолчанию.
• 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() - В Python 3 строки больше не имеют префикса «u».
• 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_PERMISSION теперь содержит 0o644 по умолчанию, чтобы избежать этой несогласованности.

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

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

• Новое значение по умолчанию для X_FRAME_OPTIONS это 'DENY' .
• Новое значение по умолчанию для SECURE_CONTENT_TYPE_NOSNIFF это True .

Дополнительные сведения об этих изменениях см. В разделе безопасности о новых возможностях Django 3.0.

Разное ¶

• ContentType.__str__() теперь включает метку app_label модели, чтобы различать модели с одинаковыми именами в разных приложениях.
• Поскольку доступ к языку в сеансе был заменен куки-файлами, он 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 в единственном числе, а все другие числовые значения во множественное число, что не всегда правильно на разных языках.
• Присваивание значения атрибуту '_id' поля ForeignKey или OneToOneField стирание значения соответствующего поля. Любой последующий доступ к этому полю приведет к новому запросу.
• 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() and 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.