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

Автоматическое AppConfig обнаружение ¶

Большинство подключаемых приложений определяют AppConfig подкласс в apps.py подмодуле. Многие определяют default_app_config переменную, указывающую на этот класс, в своих файлах __init__.py.

Когда apps.py подмодуль существует и определяет единственный AppConfig подкласс, Django теперь автоматически использует эту конфигурацию, поэтому вы можете удалить его default_app_config.

default_app_config сделало возможным объявить только путь приложения в INSTALLED_APPS (например 'django.contrib.admin' ), а не путь конфигурации приложения (например 'django.contrib.admin.apps.AdminConfig' ). Он был введен для обратной совместимости с первым стилем с намерением переключить экосистему на второй, но переключения не произошло.

С автоматическим AppConfig обнаружением default_app_config больше не требуется. Как следствие, он устарел.

См. Подробную информацию в разделе « Настройка приложений» .

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

При определении модели, если в модели не определено поле с primary_key=True неявным первичным ключом, добавляется. Типом этого неявного первичного ключа теперь можно управлять с помощью DEFAULT_AUTO_FIELD параметра и AppConfig.default_auto_field атрибута. Больше не нужно переопределять первичные ключи во всех моделях.

Сохраняя историческое поведение, значение по умолчанию DEFAULT_AUTO_FIELD - AutoField . Начиная с DEFAULT_AUTO_FIELD версии 3.2 новые проекты создаются со значением BigAutoField . Кроме того, новые приложения создаются со AppConfig.default_auto_field значением BigAutoField . В будущем выпуске Django значение по умолчанию DEFAULT_AUTO_FIELD будет изменено на BigAutoField .

Чтобы избежать нежелательных миграции в будущем, либо в явном виде установить DEFAULT_AUTO_FIELD на AutoField :

DEFAULT_AUTO_FIELD = 'django.db.models.AutoField'

или настройте его для каждого приложения:

from django.apps import AppConfig

class MyAppConfig(AppConfig):
    default_auto_field = 'django.db.models.AutoField'
    name = 'my_app'

или для каждой модели:

from django.db import models

class MyModel(models.Model):
    id = models.AutoField(primary_key=True)

В ожидании изменения значения по умолчанию при проверке системы будет выдано предупреждение, если у вас нет явной настройки для DEFAULT_AUTO_FIELD .

Функциональные показатели ¶

Новый *expressions позиционный аргумент Index() позволяет создавать функциональные индексы для выражений и функций базы данных. Например:

from django.db import models
from django.db.models import F, Index, Value
from django.db.models.functions import Lower, Upper


class MyModel(models.Model):
    first_name = models.CharField(max_length=255)
    last_name = models.CharField(max_length=255)
    height = models.IntegerField()
    weight = models.IntegerField()

    class Meta:
        indexes = [
            Index(
                Lower('first_name'),
                Upper('last_name').desc(),
                name='first_last_name_idx',
            ),
            Index(
                F('height') / (F('weight') + Value(5)),
                name='calc_idx',
            ),
        ]

Функциональные индексы добавляются к моделям с помощью Meta.indexes опции.

pymemcache поддержка ¶

Новый django.core.cache.backends.memcached.PyMemcacheCache бэкэнд кеширования позволяет использовать библиотеку pymemcache для memcached. pymemcache Требуется 3.4.0 или выше. Подробнее см. Документацию по кешированию в Django .

Новые декораторы для админки ¶

Новый display() декоратор позволяет легко добавлять параметры к пользовательским функциям отображения, которые можно использовать с list_display или readonly_fields .

Точно так же новый action() декоратор позволяет легко добавлять параметры к функциям действий, которые можно использовать с actions .

Использование @display декоратора имеет то преимущество, что теперь можно использовать @property декоратор, когда необходимо указать атрибуты в настраиваемом методе. До этого необходимо было использовать property() функцию после присвоения методу необходимых атрибутов.

Преимущество использования декораторов состоит в том, что эти параметры легче обнаружить, поскольку они могут быть предложены утилитами завершения в редакторах кода. Они просто удобны и по-прежнему устанавливают те же атрибуты для внутренних функций.

Незначительные особенности ¶

API серверной части базы данных ¶

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

• Новое DatabaseFeatures.introspected_field_types свойство заменяет эти функции:
  • can_introspect_autofield
  • can_introspect_big_integer_field
  • can_introspect_binary_field
  • can_introspect_decimal_field
  • can_introspect_duration_field
  • can_introspect_ip_address_field
  • can_introspect_positive_integer_field
  • can_introspect_small_integer_field
  • can_introspect_time_field
  • introspected_big_auto_field_type
  • introspected_small_auto_field_type
  • introspected_boolean_field_type
• Чтобы включить поддержку для покрытия индексов ( Index.include ) и покрытия уникальных ограничений ( UniqueConstraint.include ), установите DatabaseFeatures.supports_covering_indexes значение True.
• Сторонние серверные части баз данных должны реализовывать поддержку сортировки базы данных столбцов по CharField s и TextField s или set DatabaseFeatures.supports_collation_on_charfield and DatabaseFeatures.supports_collation_on_textfield to False. Если недетерминированные сопоставления не поддерживаются, установите supports_non_deterministic_collations значение False.
• DatabaseOperations.random_function_sql() удален в пользу новой Random функции базы данных.
• DatabaseOperations.date_trunc_sql() и DatabaseOperations.time_trunc_sql() теперь возьмите необязательный tzname аргумент для усечения в определенном часовом поясе.
• DatabaseClient.runshell() теперь получает аргументы и необязательный словарь с переменными среды для основного клиента командной строки из DatabaseClient.settings_to_cmd_args_env() метода. Сторонние серверные части баз данных должны быть реализованы DatabaseClient.settings_to_cmd_args_env() или переопределены DatabaseClient.runshell().
• Сторонние серверные части баз данных должны поддерживать функциональные индексы ( Index.expressions ) или иметь DatabaseFeatures.supports_expression_indexes значение False. Если COLLATE не является частью инструкции, установите значение .CREATE INDEX DatabaseFeatures.collate_as_index_expression True

django.contrib.admin ¶

• Ссылки пагинации в админке теперь индексируются 1 вместо 0, т.е. строка запроса для первой страницы ?p=1 вместо ?p=0.
• Новое универсальное представление администратора нарушит шаблоны URL-адресов, маршрутизируемые после URL-адресов администратора и соответствующие префиксу URL-адреса администратора. Вы можете настроить порядок URL или, в случае необходимости, установить AdminSite.final_catch_all_view на False отключение приема всей точки зрения. Подробнее см. Что нового в Django 3.2 .
• Минифицированные файлы JavaScript больше не включены в админку. Если вам необходимо минимизировать эти файлы, рассмотрите возможность использования стороннего приложения или внешнего инструмента сборки. Минифицированные поставляемые файлы JavaScript, упакованные с администратором (например, jquery.min.js ), по-прежнему включены.
• ModelAdmin.prepopulated_fields больше не удаляет английские стоп-слова, такие как 'a' или 'an'.

django.contrib.gis ¶

• Поддержка PostGIS 2.2 удалена.
• Серверная часть Oracle теперь клонирует полигоны (и коллекции геометрии, содержащие полигоны) перед их переориентацией и сохранением в базе данных. Они больше не видоизменяются. Вы можете заметить это, если используете многоугольники после сохранения модели.

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

Поддержка PostgreSQL 9.5 в апстриме заканчивается в феврале 2021 года. Django 3.2 поддерживает PostgreSQL 9.6 и выше.

Прекращена поддержка MySQL 5.6 ¶

Окончание восходящей поддержки MySQL 5.6 - апрель 2021 года. Django 3.2 поддерживает MySQL 5.7 и выше.

Разное ¶

• Django теперь поддерживает не- pytz часовые пояса, такие как zoneinfo модуль Python 3.9+ и его бэкпорт.

• Недокументированный SpatiaLiteOperations.proj4_version() метод переименован в proj_version().

• slugify() теперь удаляет начальные и конечные дефисы и подчеркивания.

• Эти intcomma и intword фильтры шаблонов больше не зависит от USE_L10N настройки.

• Поддержка argon2-cffi <19.1.0 удалена.

• Ключи кеша больше не включают язык, когда интернационализация отключена ( ) и включена локализация ( ). После обновления до Django 3.2 в таких конфигурациях первым запросом на любое ранее закешированное значение будет промах в кеше.USE_I18N = False USE_L10N = True

• ForeignKey.validate() теперь использует, _base_manager а не _default_manager проверяет наличие связанных экземпляров.

• Когда приложение определяет AppConfig подкласс в apps.py подмодуле, Django теперь автоматически использует эту конфигурацию, даже если она не включена в default_app_config. Установите в подклассе, если вам нужно предотвратить такое поведение. Подробнее см. Что нового в Django 3.2 .default = False AppConfig

• Теперь возникает необходимость создания абстрактной модели TypeError.

• Аргументы setup_databases() ключевого слова для теперь содержат только ключевые слова.

• Недокументированная django.utils.http.limited_parse_qsl() функция удалена. Пожалуйста, используйте urllib.parse.parse_qsl() вместо этого.

• django.test.utils.TestContextDecorator now использует addCleanup() так, чтобы очистки, зарегистрированные в setUp() методе, вызывались раньше TestContextDecorator.disable().

• SessionMiddleware теперь вызывает SessionInterrupted исключение, а не SuspiciousOperation когда сеанс уничтожается в параллельном запросе.

• Оператор django.db.models.Field равенства теперь правильно различает унаследованные экземпляры полей в разных моделях. Кроме того, теперь определен порядок таких полей.

• Недокументированная django.core.files.locks.lock() функция теперь возвращается, False если файл не может быть заблокирован, вместо повышения BlockingIOError .

• Механизм сброса пароля теперь делает токены недействительными при изменении электронной почты пользователя.

• makemessages Команда больше не обрабатывает недопустимые языковые стандарты, указанные с помощью параметра, если они содержат дефисы ( ).makemessages --locale '-'

• Поле django.contrib.auth.forms.ReadOnlyPasswordHashField формы теперь disabled по умолчанию. Поэтому UserChangeForm.clean_password() больше не требуется возвращать начальное значение.

• cache.get_many(), get_or_set(), has_key(), incr(), decr(), incr_version(), И decr_version() операции кэша теперь корректно ручка None хранится в кэше, таким же образом , как и любое другое значение, вместо того , чтобы вести себя так , как будто ключ не существует.

  Из-за python-memcached ограничения прежнее поведение для устаревшего MemcachedCache бэкэнда сохраняется .

• Минимальная поддерживаемая версия SQLite увеличена с 3.8.3 до 3.9.0.

• CookieStorage теперь хранит сообщения в Формат, соответствующий RFC 6265 . Поддержка файлов cookie, использующих старый формат, сохраняется до Django 4.1.

• Минимальная поддерживаемая версия asgiref увеличена с 3.2.10 до 3.3.2.

Разное ¶

• Назначение объектов, которые не поддерживают создание глубоких копий с помощью copy.deepcopy() атрибутов класса TestCase.setUpTestData() , устарело.
• Использование логического значения в BaseCommand.requires_system_checks устарело. Используйте '__all__' вместо True, и [] (пустой список) вместо False.
• whitelist Аргумент и domain_whitelist атрибут EmailValidator устарели. Используйте allowlist вместо whitelist и domain_allowlist вместо domain_whitelist. Возможно, вам придется переименовать whitelist существующие миграции.
• default_app_config Переменная конфигурация приложения устарела, из - за теперь автоматическое AppConfig открытие. Подробнее см. Что нового в Django 3.2 .
• Автоматический вызов repr() набора запросов в TransactionTestCase.assertQuerysetEqual() по сравнению со строковыми значениями устарел. Если вам нужно предыдущее поведение, явно установите transform значение repr.
• django.core.cache.backends.memcached.MemcachedCache Бэкенд нежелателен python-memcached имеют некоторые проблемы и , кажется, никто не поддерживались. Используйте django.core.cache.backends.memcached.PyMemcacheCache или django.core.cache.backends.memcached.PyLibMCCache вместо.
• Формат сообщений, используемых django.contrib.messages.storage.cookie.CookieStorage в Django, отличается от формата, создаваемого более старыми версиями Django. Поддержка старого формата сохраняется до Django 4.1.