Миграции схемы¶

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

Миграции описаны в собственной документации, но вот некоторые ключевые особенности:

• syncdb устарел и заменен на migrate. Не волнуйтесь, вызовы syncdb будут работать как прежде.

• Новая команда makemigrations предоставляет простой способ автоматического обнаружения изменений в ваших моделях и выполнения для них миграции.

  django.db.models.signals.pre_syncdb и django.db.models.signals.post_syncdb устарели и заменены на pre_migrate и post_migrate соответственно. Эти новые сигналы имеют несколько иные аргументы. Подробности смотрите в документации.

• Методallow_syncdb на маршрутизаторах баз данных теперь называетсяallow_migrate, но по-прежнему выполняет ту же функцию. Маршрутизаторы с методами allow_syncdb по-прежнему будут работать, но это имя метода устарело, и вам следует изменить его как можно скорее (не требуется ничего, кроме переименования).

• Фикстуры initial_data больше не загружаются для приложений с миграцией; Если вы хотите загрузить исходные данные для приложения, мы предлагаем вам создать миграцию для вашего приложения и определить операцию RunPython или RunSQL в разделе operations миграции.

• Поведение теста отката отличается для приложений с миграцией; в частности, Django больше не будет эмулировать откаты в нетранзакционных базах данных или внутри TransactionTestCase , если специально не запрошено.

• Не рекомендуется, чтобы приложения без миграции зависели от приложений с миграциями (имели ForeignKey или ManyToManyField to).

Рефакторинг загрузки приложений¶

Исторически приложения Django были тесно связаны с моделями. Синглтон, известный как «кэш приложений», обрабатывал как установленные приложения, так и модели. Модуль моделей использовался в качестве идентификатора приложений во многих API.

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

Улучшения на данный момент включают в себя:

• Приложения могут запускать код при запуске, прежде чем Django сделает что-либо еще, с помощью метода ready() их конфигурации.

• Метки приложения корректно назначаются моделям, даже если они определены вне файла models.py. Вам больше не нужно явно устанавливать app_label.

• Можно полностью опустить файл models.py, если в приложении нет моделей.

• Приложения можно переименовывать с помощью атрибута label конфигураций приложений, чтобы обойти конфликты меток.

• Имена приложений можно настроить в администраторе с помощью verbose_name конфигураций приложений.

• Администратор автоматически вызывает autodiscover() при запуске Django. Следовательно, вы можете удалить эту строку из вашего URLconf.

• Django импортирует все конфигурации и модели приложения сразу после запуска, используя детерминированный и простой процесс. Это должно облегчить диагностику проблем импорта, таких как циклы импорта.

Новый метод для подклассов Field¶

Чтобы облегчить миграцию схем и упростить добавление составных ключей в будущих выпусках Django, API Field теперь имеет новый обязательный метод: deconstruct().

Этот метод не принимает аргументов и возвращает кортеж из четырех элементов:

• name: имя атрибута поля в его родительской модели или Нет, если оно не является частью модели.

• path: точечный путь Python к классу этого поля, включая имя класса.

• args: позиционные аргументы в виде списка.

• kwargs: аргументы ключевых слов в виде диктата.

Эти четыре значения позволяют сериализовать любое поле в файл, а также позволяют безопасно копировать поле — обе важные части этих новых функций.

Это изменение не должно затронуть вас, если вы не пишете собственные подклассы Field; в этом случае вам может потребоваться переопределить метод deconstruct(), если ваш подкласс каким-либо образом изменит сигнатуру метода __init__. Если ваше поле просто наследует встроенное поле Django и не переопределяет __init__, никаких изменений не требуется.

Если вам все же нужно переопределить deconstruct(), лучше всего начать со встроенных полей Django (django/db/models/fields/__init__.py) в виде нескольких полей, включая DecimalField и DateField, переопределить их и показать, как вызывать метод в суперклассе и просто добавлять или удалять дополнительные аргументы.

Это также означает, что все аргументы полей сами по себе должны быть сериализуемыми; Чтобы узнать, что мы считаем сериализуемым, и узнать, как сделать сериализуемыми ваши собственные классы, прочитайте документацию по сериализации миграции.

Вызов пользовательских методов QuerySet из Manager¶

Исторически сложилось так, что рекомендуемым способом создания повторно используемых запросов модели было создание методов в специальном классе Manager. Проблема с этим подходом заключалась в том, что после первого вызова метода вы возвращали экземпляр QuerySet и не могли вызывать дополнительные методы пользовательского менеджера.

Хотя это и не документировано, эту проблему обычно решали путем создания специального QuerySet, чтобы пользовательские методы могли быть объединены в цепочку; но решение имело ряд недостатков:

• Пользовательский QuerySet и его пользовательские методы были потеряны после первого вызова values() или values_list().

• Написание собственного Manager по-прежнему было необходимо для возврата пользовательского класса QuerySet, и все методы, которые были нужны для Manager, должны были быть проксированы в QuerySet. Весь процесс противоречил принципу DRY.

Метод класса QuerySet.as_manager() теперь может напрямую создать Manager с помощью методов QuerySet:

class FoodQuerySet(models.QuerySet):
    def pizzas(self):
        return self.filter(kind="pizza")

    def vegetarian(self):
        return self.filter(vegetarian=True)


class Food(models.Model):
    kind = models.CharField(max_length=50)
    vegetarian = models.BooleanField(default=False)
    objects = FoodQuerySet.as_manager()


Food.objects.pizzas().vegetarian()

Использование специального менеджера при обходе обратных отношений¶

Теперь можно указать собственный менеджер при прохождении обратной связи:

class Blog(models.Model):
    pass


class Entry(models.Model):
    blog = models.ForeignKey(Blog)

    objects = models.Manager()  # Default Manager
    entries = EntryManager()  # Custom Manager


b = Blog.objects.get(id=1)
b.entry_set(manager="entries").all()

Новая система проверки системы¶

Мы добавили новую Системную систему проверки для обнаружения распространенных проблем (например, недопустимых моделей) и предоставления подсказок по их решению. Платформа является расширяемой, поэтому вы можете добавлять собственные проверки для своих приложений и библиотек.

Для выполнения системных проверок вы используете команду управления check. Эта команда заменяет старую команду управления validate.

Новый объект Prefetch для расширенных операций prefetch_based.¶

Новый объект Prefetch позволяет настраивать операции предварительной выборки.

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

Это позволяет выполнять такие функции, как фильтрация предварительно выбранных отношений, вызов select_related() из предварительно выбранных отношений или предварительная выборка одного и того же отношения несколько раз с разными наборами запросов. См. prefetch_related() для более подробной информации.

Ярлыки администратора поддерживают часовые пояса¶

Ярлыки «сегодня» и «сейчас» рядом с виджетами ввода даты и времени в администраторе теперь работают в текущем часовом поясе. Раньше они использовали часовой пояс браузера, что могло привести к сохранению неправильного значения, если оно не соответствовало текущему часовому поясу на сервере.

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

Использование курсоров базы данных в качестве менеджеров контекста¶

До Python 2.7 курсоры базы данных можно было использовать в качестве менеджера контекста. Курсор конкретного бэкэнда определял поведение контекстного менеджера. Поведение поиска магических методов было изменено в Python 2.7, и курсоры больше нельзя было использовать в качестве менеджеров контекста.

Django 1.7 позволяет использовать курсор в качестве менеджера контекста. То есть можно использовать следующее:

with connection.cursor() as c:
    c.execute(...)

вместо:

c = connection.cursor()
try:
    c.execute(...)
finally:
    c.close()

Пользовательские поиски¶

Теперь можно писать собственные поиски и преобразования для ORM. Пользовательские поисковые запросы работают так же, как встроенные поисковые запросы Django (например, lte, icontains), а преобразования — это новая концепция.

Класс django.db.models.Lookup предоставляет возможность добавлять операторы поиска для полей модели. В качестве примера можно добавить оператор day_lte для DateFields.

Класс django.db.models.Transform позволяет преобразовывать значения базы данных перед окончательным поиском. Например, можно написать преобразование «год», которое извлекает год из значения поля. Преобразования позволяют создавать цепочки. После добавления преобразования year в DateField можно фильтровать преобразованное значение, например qs.filter(author__birthdate__year__lte=1981).

Дополнительную информацию о пользовательских поисках и преобразованиях см. в документации пользовательских поисков.

Улучшения в обработке ошибок формы.¶

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

allow_syncdb / allow_migrate¶

Хотя Django по-прежнему будет использовать методыallow_syncdb, даже если они должны быть переименованы вallow_migrate, существует небольшая разница в том, какие модели передаются этим методам.

Для приложений с миграцией теперь allow_migrate будет передаваться исторические модели, которые представляют собой модели со специальными версиями без пользовательских атрибутов, методов или менеджеров. Убедитесь, что ваши методыallow_migrate относятся только к полям или другим элементам в model._meta.

начальные_данные¶

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

Вместо этого вам рекомендуется загружать исходные данные при миграции, если они вам нужны (используя операцию RunPython и классы вашей модели); это имеет дополнительное преимущество: ваши исходные данные не будут нуждаться в обновлении каждый раз при изменении схемы.

Кроме того, как и остальная часть старого кода syncdb Django, initial_data устарела и будет удалена в Django 1.9.

deconstruct() и сериализуемость¶

Django теперь требует, чтобы все классы полей и все аргументы их конструкторов были сериализуемыми. Если вы каким-либо образом измените подпись конструктора в своем пользовательском поле, вам потребуется реализовать метод deconstruct(); мы расширили документацию по настраиваемым полям, добавив инструкции по реализации этого метода.

Требование, чтобы все аргументы поля были serializable, означает, что любые экземпляры пользовательских классов, передаваемые в конструкторы Field - например, такие как пользовательские подклассы Storage - должны также иметь deconstruct метод, определенный для них, а также, хотя Django предоставляет удобный декоратор классов, который будет работать для большинства приложений.

Изменения в загрузке приложений¶

>>> import django
>>> django.setup()

import django.core.handlers.wsgi

application = django.core.handlers.wsgi.WSGIHandler()

from django.core.wsgi import get_wsgi_application

application = get_wsgi_application()

Команды управления и порядок установки INSTALLED_APPS¶

Когда несколько приложений предоставляют команды управления с одинаковым именем, Django загружает команду из приложения, которое указано первым в INSTALLED_APPS. Предыдущие версии загружали команду из приложения, которое появлялось последним.

Это приводит к тому, что обнаружение команд управления соответствует другим частям Django, которые зависят от порядка INSTALLED_APPS, таких как статические файлы, шаблоны и переводы.

Конструктор ValidationError и внутреннее хранилище¶

Поведение конструктора ValidationError изменилось, когда он получил в качестве аргумента контейнер ошибок (например, список или ErrorList):

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

• Он не сохраняет данный контейнер, а копирует его содержимое в свое внутреннее хранилище; ранее сам контейнер добавлялся к экземпляру ValidationError и использовался в качестве внутреннего хранилища.

Это означает, что если вы получаете доступ к внутренним хранилищам ValidationError, таким как error_list; error_dict; или возвращаемое значение update_error_dict(), вы можете найти экземпляры ValidationError, где вы ранее могли найти строки.

Также, если вы напрямую присвоили возвращаемое значение update_error_dict() для Form._errors, вы можете случайно добавить экземпляры list там, где ожидаются экземпляры ErrorList. Это проблема, потому что в отличие от простого списка, ErrorList знает, как обрабатывать экземпляры ValidationError.

Большинство случаев использования, требующих использования этих частных API, теперь покрываются недавно представленным методом Form.add_error():

# Old pattern:
try:
    ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# New pattern:
try:
    ...
except ValidationError as e:
    self.add_error(None, e)

Если вам нужна совместимость с Django <= 1.6 и 1.7, вы не можете использовать Form.add_error(), поскольку он не был доступен до Django 1.7, но вы можете использовать следующий обходной путь для преобразования любого list в ErrorList:

try:
    ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# Additional code to ensure ``ErrorDict`` is exclusively
# composed of ``ErrorList`` instances.
for field, error_list in self._errors.items():
    if not isinstance(error_list, self.error_class):
        self._errors[field] = self.error_class(error_list)

Поведение LocMemCache в отношении ошибок травления¶

В предыдущих версиях Django существовало несоответствие относительно того, как ошибки Pickle обрабатываются различными серверами кэширования. django.core.cache.backends.locmem.LocMemCache используется для молчаливого сбоя при возникновении такой ошибки, что несовместимо с другими бэкэндами и приводит к ошибкам, специфичным для кэша. Это было исправлено в Django 1.7, подробности см. в #21200.

Ключи кэша теперь генерируются на основе абсолютного URL-адреса запроса.¶

Предыдущие версии Django генерировали ключи кэша, используя путь запроса и строку запроса, но не схему или хост. Если приложение Django обслуживало несколько поддоменов или доменов, ключи кэша могли конфликтовать. В Django 1.7 ключи кэша различаются в зависимости от абсолютного URL-адреса запроса, включая схему, хост, путь и строку запроса. Например, URL-часть ключа кэша теперь генерируется из «https://www.example.com/path/to/?key=val», а не из «/path/to/?key=val». Ключи кэша, созданные Django 1.7, будут отличаться от ключей, созданных более старыми версиями Django. После обновления до Django 1.7 первый запрос к любому ранее кэшированному URL-адресу будет промахом в кэше.

Передача None в Manager.db_manager()¶

В предыдущих версиях Django можно было использовать db_manager(using=None) для экземпляра менеджера модели, чтобы получить экземпляр менеджера с использованием поведения маршрутизации по умолчанию, переопределяя любую маршрутизацию базы данных, заданную вручную. В Django 1.7 значение None, переданное в db_manager, создаст маршрутизатор, который сохраняет любую назначенную вручную маршрутизацию базы данных — менеджер не сбрасывается. Это было необходимо для устранения несогласованности в способе каскадной передачи информации о маршрутизации по соединениям. Подробнее см. в #13724.

pytz может потребоваться¶

Если ваш проект обрабатывает даты до 1970 года или после 2037 года и Django выдает ошибку ValueError при обнаружении таких дат, вам придется установить pytz. Эта проблема может возникнуть у вас, если вы используете форматы дат Django, связанные с часовым поясом, или django.contrib.syndiction.

Методы remove() и clear() связанных менеджеров¶

Методы remove() и clear() связанных менеджеров, созданных ForeignKey, GenericForeignKey и ManyToManyField, страдали от ряда проблем. Некоторые операции выполняли несколько запросов на изменение данных, не заключая их в транзакцию, а некоторые операции не учитывали фильтрацию по умолчанию, когда она присутствовала (т. е. когда менеджер по умолчанию в связанной модели реализовал собственный get_queryset()).

Исправление проблем привело к некоторым обратно несовместимым изменениям:

• Реализация по умолчанию remove() для менеджеров, связанных с ForeignKey, изменилась с серии вызовов Model.save() на одиночный вызов QuerySet.update(). Это изменение означает, что сигналы pre_save и post_save больше не отправляются. Вы можете использовать аргумент ключевого слова Bulk=False, чтобы вернуться к предыдущему поведению.

• Методы remove() и clear() для менеджеров, связанных с GenericForeignKey, теперь выполняют массовое удаление. Метод Model.delete() больше не вызывается для каждого экземпляра. Вы можете использовать аргумент ключевого слова Bulk=False, чтобы вернуться к предыдущему поведению.

• Методы remove() и clear() для менеджеров, связанных с ManyToManyField, выполняют вложенные запросы при использовании фильтрации, что может быть или не быть проблемой в зависимости от вашей базы данных и самих ваших данных. См. эту заметку для более подробной информации.

Стратегия перенаправления входа администратора¶

Исторически сайт администрирования Django передавал запрос от неавторизованного или неаутентифицированного пользователя непосредственно в представление входа в систему без перенаправления HTTP. В Django 1.7 это поведение изменилось, чтобы соответствовать более традиционному рабочему процессу, где любой несанкционированный запрос к странице администратора будет перенаправлен (по коду состояния HTTP 302) на страницу входа, с параметром next, установленным на ссылающийся путь. Туда пользователь будет перенаправлен после успешного входа в систему.

Также обратите внимание, что форма входа администратора была обновлена ​​и теперь не содержит поля this_is_the_login_form (теперь не используемого), а для кода ValidationError был установлен более обычный ключ invalid_login.

select_for_update() требует транзакции¶

Исторически запросы, использующие select_for_update(), могли выполняться в режиме автоматической фиксации вне транзакции. До Django 1.6 режим автоматических транзакций Django позволял использовать его для блокировки записей до следующей операции записи. В Django 1.6 появилась автофиксация на уровне базы данных; с тех пор выполнение в таком контексте аннулирует эффект select_for_update(). Таким образом, теперь предполагается, что это ошибка и вызывает исключение.

Это изменение было сделано потому, что такие ошибки могут быть вызваны включением приложения, которое ожидает глобальных транзакций (например, ATOMIC_REQUESTS со значением True) или старым поведением автофиксации Django в проекте, который работает без них; кроме того, такие ошибки могут проявляться как ошибки, приводящие к повреждению данных. Это также было сделано в Django 1.6.3.

Это изменение может привести к сбою теста, если вы используете select_for_update() в тестовом классе, который является подклассом TransactionTestCase, а не TestCase.

Промежуточное программное обеспечение Contrib удалено из стандартного MIDDLEWARE_CLASSES.¶

Рефакторинг app-loading устарел с использованием моделей из приложений, которые не являются частью настройки INSTALLED_APPS. Это выявило несовместимость между настройкой по умолчанию INSTALLED_APPS и MIDDLEWARE_CLASSES в глобальных настройках по умолчанию (django.conf.global_settings). Чтобы синхронизировать эти настройки и предотвратить предупреждения об устаревании при выполнении таких действий, как тестирование повторно используемых приложений с минимальными настройками, SessionMiddleware, AuthenticationMiddleware, и MessageMiddleware были удалены из значений по умолчанию. Эти классы по-прежнему будут включены в настройки по умолчанию, созданные startproject. Это изменение не повлияет на большинство проектов, но если вы ранее не объявляли MIDDLEWARE_CLASSES в настройках вашего проекта и не полагались на глобальное значение по умолчанию, вам следует убедиться, что новые значения по умолчанию соответствуют потребностям вашего проекта. Вам также следует проверить наличие кода, который обращается напрямую к django.conf.global_settings.MIDDLEWARE_CLASSES.

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

• Методу django.core.files.uploadhandler.FileUploadHandler.new_file() теперь передается дополнительный параметр content_type_extra. Если у вас есть собственный FileUploadHandler, реализующий new_file(), убедитесь, что он принимает этот новый параметр.

• ModelFormSets больше не удаляет экземпляры при вызове save(commit=False). См. can_delete для получения инструкций о том, как вручную удалять объекты из удаленных форм.

• Загрузка пустых фикстур выдает RuntimeWarning, а не вызывает CommandError.

• django.contrib.staticfiles.views.serve() теперь вызывает исключение Http404 вместо ImproperlyConfigured, когда DEBUG имеет значение False. Это изменение устраняет необходимость условно добавлять представление в корневой URLconf, что, в свою очередь, делает его безопасным для обратного изменения по имени. Он также лишает посетителей возможности генерировать ложные ошибки HTTP 500, запрашивая статические файлы, которые не существуют или еще не были собраны.

• Метод django.db.models.Model.__eq__() теперь определен таким образом, что экземпляры прокси-модели и ее базовой модели считаются равными при совпадении первичных ключей. Раньше только экземпляры одного и того же класса считались равными при совпадении первичного ключа.

• Метод django.db.models.Model.__eq__() изменился таким образом, что два экземпляра Model без значений первичного ключа не будут считаться равными (если только они не являются одним и тем же экземпляром).

• Метод django.db.models.Model.__hash__() теперь будет вызывать TypeError при вызове в экземпляре без значения первичного ключа. Это сделано для того, чтобы избежать изменяемых значений __hash__ в контейнерах.

• AutoField Столбцы в базах данных SQLite теперь будут создаваться с использованием опции AUTOINCREMENT, которая гарантирует монотонное приращение. Это приведет к изменению поведения нумерации первичных ключей в SQLite, которое станет совместимым с большинством других баз данных SQL. Это будет применяться только к вновь созданным таблицам. Если у вас есть база данных, созданная с помощью более старой версии Django, вам потребуется перенести ее, чтобы воспользоваться этой функцией. Например, вы можете сделать следующее:

  1. Используйте dumpdata, чтобы сохранить ваши данные.

  2. Переименуйте существующий файл базы данных (сохраните его как резервную копию).

  3. Запустите migrate, чтобы создать обновленную схему.

  4. Используйте loaddata для импорта приборов, которые вы экспортировали в (1).

• django.contrib.auth.models.AbstractUser больше не определяет метод get_absolute_url(). Старое определение возвращало "/users/%s/" % urlquote(self.username), что было произвольным, поскольку приложения могут определять или не определять такой URL-адрес в urlpatterns. Определите метод get_absolute_url() для своего собственного пользовательского объекта или используйте ABSOLUTE_URL_OVERRIDES, если вам нужен URL-адрес для вашего пользователя.

• Статическая функциональность обслуживания ресурсов класса django.test.LiveServerTestCase была упрощена: теперь он может обслуживать только контент, уже присутствующий в STATIC_ROOT, при запуске тестов. Возможность прозрачного обслуживания всех статических ресурсов (аналогично тому, что можно получить с помощью DEBUG = True во время разработки) была перенесена в новый класс, который находится в приложении staticfiles (тот, который фактически отвечает за такую ​​функцию): django.contrib.staticfiles.testing.StaticLiveServerTestCase. Другими словами, LiveServerTestCase сам по себе менее мощный, но в то же время в нем меньше магии.

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

• Старый синтаксис URI кэша (например, "locmem://") больше не поддерживается. Он по-прежнему работал, хотя и не был задокументирован или официально поддержан. Если вы все еще используете его, обновите синтаксис CACHES до текущего.

• Порядок полей «Формы» по умолчанию в случае наследования изменился и теперь соответствует обычному Python MRO. Поля теперь обнаруживаются путем итерации MRO в обратном порядке, при этом самый верхний класс идет последним. Это влияет на вас только в том случае, если вы полагались на порядок полей по умолчанию, имея поля, определенные как в текущем классе *, так и * в родительской Form.

• Аргумент required SelectDateWidget был удален. Этот виджет теперь учитывает атрибут is_required поля формы, как и другие виджеты.

• Widget.is_hidden теперь является свойством только для чтения, получая свое значение путем самоанализа input_type == 'hidden'.

• select_related() теперь объединяется так же, как и другие подобные вызовы, такие как prefetch_related. То есть select_related(„foo“, „bar“)`` эквивалентен select_related('foo').select_lated('bar'). Раньше последнее было эквивалентно select_related('bar').

• GeoDjango прекратил поддержку GEOS <3.1.

• Метод init_connection_state серверной части базы данных теперь выполняется в режиме автофиксации (если вы не установили для AUTOCOMMIT значение False). Если вы поддерживаете собственную базу данных, вам следует проверить этот метод.

• Атрибут django.db.backends.BaseDatabaseFeatures.allows_primary_key_0 был переименован в allows_auto_pk_0, чтобы лучше его описать. Это True для всех баз данных, включенных в Django, за исключением MySQL, который разрешает первичные ключи со значением 0. Он запрещает только автоинкремент первичных ключей со значением 0.

• Затенение полей модели, определенных в родительской модели, запрещено, поскольку это создает неоднозначность в ожидаемом поведении модели. Кроме того, конфликты полей в иерархии наследования модели приводят к ошибке проверки системы. Например, если вы используете множественное наследование, вам необходимо определить собственные поля первичного ключа в родительских моделях, иначе поля id по умолчанию будут конфликтовать. Подробности смотрите в разделе Множественное наследование.

• django.utils.translation.parse_accept_lang_header() теперь возвращает локали в нижнем регистре, а не в том регистре, который был предусмотрен. Поскольку локали следует обрабатывать без учета регистра, это позволяет нам ускорить определение локали.

• django.utils.translation.get_language_from_path() и django.utils.translation.trans_real.get_supported_language_variant() больше не имеют аргумента supported.

• Представление shortcut в django.contrib.contenttypes.views теперь поддерживает URL-адреса, зависящие от протокола (например, //example.com).

• GenericRelation теперь поддерживает необязательный аргумент linked_query_name``. Установка «related_query_name» добавляет связь из связанного объекта обратно к типу контента для фильтрации, упорядочивания и других операций запроса.

• При запуске тестов на PostgreSQL пользователю USER потребуется доступ на чтение к встроенной базе данных postgres. Это вместо предыдущего поведения при подключении к фактической нетестовой базе данных.

• В рамках Системной системы проверки, поля, модели и менеджеры моделей реализуют метод check(), зарегистрированный в системе проверки. Если у вас есть существующий метод check() для одного из этих объектов, вам нужно будет переименовать его.

• Как отмечалось выше в разделе «Кэш» раздела «Второстепенные функции», определение аргумента TIMEOUT параметра CACHES как None приведет к установке ключей кэша как «не истекающих». Раньше при использовании бэкенда memcache параметр TIMEOUT, равный 0, устанавливал ключи с неограниченным сроком действия, но это несовместимо с поведением set("key", "value", timeout=0), использующим установку и истечение срока действия (т.е. без кэширования). Если вам нужны ключи с неограниченным сроком действия, обновите настройки, чтобы использовать «Нет» вместо «0», поскольку последний теперь также обозначает в настройках возможность установки и истечения срока действия.

• Команды управления sql* теперь учитывают метод allow_migrate() DATABASE_ROUTERS. Если у вас есть модели, синхронизированные с базами данных, отличными от стандартных, используйте флаг –database, чтобы получить SQL для этих моделей (ранее они всегда включались в выходные данные).

• Декодирование строки запроса из URL-адресов теперь возвращается к кодировке ISO-8859-1, если входные данные недействительны в формате UTF-8.

• При добавлении django.contrib.auth.middleware.SessionAuthenticationMiddleware к шаблону проекта по умолчанию (только до версии 1.7.2) база данных должна быть создана перед доступом к странице с помощью runserver.

• Добавление аргумента schemes в URLValidator будет выглядеть как обратно несовместимое изменение, если вы ранее использовали собственное регулярное выражение для проверки схем. Любая схема, не указанная в schemes, не пройдет проверку, даже если регулярное выражение соответствует данному URL-адресу.

django.core.cache.get_cache¶

django.core.cache.get_cache был заменен на django.core.cache.cache`.

django.utils.dictconfig/django.utils.importlib¶

django.utils.dictconfig и django.utils.importlib были копиями соответственно logging.config и importlib, предоставленных для версий Python до 2.7. Они устарели.

django.utils.module_loading.import_by_path¶

Текущая функция django.utils.module_loading.import_by_path перехватывает исключения AttributeError, ImportError и ValueError и повторно вызывает :exc:~django.core.Exceptions.ImproperlyConfigured. Такое маскирование исключений усложняет диагностику проблем циклического импорта, поскольку создается впечатление, что проблема исходит изнутри Django. Он устарел в пользу import_string().

django.utils.tzinfo¶

django.utils.tzinfo предоставляет два подкласса tzinfo, LocalTimezone и FixedOffset. Они устарели в пользу более правильных альтернатив, предоставляемых django.utils.timezone, django.utils.timezone.get_default_timezone() и django.utils.timezone.get_fixed_timezone().

django.utils.unittest¶

django.utils.unittest обеспечивал единый доступ к библиотеке unittest2 во всех версиях Python. Поскольку unittest2 стал модулем unittest стандартной библиотеки в Python 2.7, а в Django 1.7 прекращена поддержка старых версий Python, этот модуль больше не полезен. Это устарело. Вместо этого используйте unittest.

django.utils.datastructures.SortedDict¶

Поскольку OrderedDict был добавлен в стандартную библиотеку Python 2.7, SortedDict больше не нужен и устарел.

Два дополнительных устаревших метода, предоставляемых SortedDict (insert() и value_for_index()), были удалены. Если вы полагались на эти методы для изменения структур, таких как поля формы, теперь вам следует рассматривать эти OrderedDict как неизменяемые объекты и переопределять их для изменения их содержимого.

Например, вы можете захотеть переопределить MyFormClass.base_fields (хотя этот атрибут не считается общедоступным API), чтобы изменить порядок полей для всех экземпляров MyFormClass; или аналогичным образом вы можете переопределить self.fields изнутри MyFormClass.__init__(), чтобы изменить поля для конкретного экземпляра формы. Например (из самого Django):

PasswordChangeForm.base_fields = OrderedDict(
    (k, PasswordChangeForm.base_fields[k])
    for k in ["old_password", "new_password1", "new_password2"]
)

Пользовательское расположение SQL для пакета моделей¶

Раньше, если модели были организованы в пакет (myapp/models/), а не просто в myapp/models.py, Django искал исходные данные SQL в myapp/models/sql/. Эта ошибка была исправлена, и Django будет выполнять поиск в myapp/sql/, как описано в документации. После устранения этой проблемы были добавлены миграции, которые устарели из-за исходных данных SQL. Таким образом, хотя это изменение все еще существует, прекращение поддержки не имеет значения, поскольку вся функция будет удалена в Django 1.9.

Реорганизация django.contrib.sites¶

django.contrib.sites предоставляет ограниченную функциональность, если ее нет в INSTALLED_APPS. Рефакторинг загрузки приложений добавляет некоторые ограничения в этой ситуации. Как следствие, два объекта были перемещены, а старые местоположения устарели:

• RequestSite теперь находится в django.contrib.sites.requests.

• get_current_site() теперь находится в django.contrib.sites.shortcuts.

Атрибут declared_fieldsets в ModelAdmin¶

ModelAdmin.declared_fieldsets устарел. Несмотря на то, что это частный API, он будет регулярно устаревать. Этот атрибут в основном использовался методами, которые обходили ModelAdmin.get_fieldsets(), но это было сочтено ошибкой и исправлено.

Реорганизация django.contrib.contenttypes¶

Поскольку django.contrib.contenttypes.generic определяет объекты, связанные как с администратором, так и с моделью, импорт этого модуля может вызвать неожиданные побочные эффекты. Как следствие, его содержимое было разделено на подмодули contenttypes, а модуль django.contrib.contenttypes.generic устарел:

• GenericForeignKey и GenericRelation теперь живут в fields.

• BaseGenericInlineFormSet и generic_inlineformset_factory() теперь живут в forms.

• GenericInlineModelAdmin, GenericStackedInline и GenericTabularInline теперь живут в admin.

синкдб¶

Команда syncdb устарела в пользу новой команды migrate. migrate принимает те же аргументы, что и syncdb, плюс еще несколько, поэтому можно безопасно просто изменить имя, по которому вы звоните, и ничего больше.

Модули util переименованы в utils¶

Следующие экземпляры util.py в кодовой базе Django были переименованы в utils.py с целью унифицировать все ссылки на util и utils:

• django.contrib.admin.util

• django.contrib.gis.db.backends.util

• django.db.backends.util

• django.forms.util

Метод get_formsets в ModelAdmin¶

ModelAdmin.get_formsets устарел в пользу нового get_formsets_with_inlines(), чтобы лучше обрабатывать случай выборочного отображения встроенных строк в ModelAdmin.

IPAddressField¶

Поля django.db.models.IPAddressField и django.forms.IPAddressField устарели в пользу django.db.models.GenericIPAddressField и django.forms.GenericIPAddressField.

Метод BaseMemcachedCache._get_memcache_timeout¶

Метод BaseMemcachedCache._get_memcache_timeout() был переименован в get_backend_timeout(). Несмотря на то, что это частный API, он будет устаревшим.

Варианты сериализации естественных ключей¶

Опции --natural и -n для dumpdata устарели. Вместо этого используйте dumpdata --natural-foreign.

Аналогично, аргумент use_natural_keys для serializers.serialize() устарел. Вместо этого используйте use_natural_foreign_keys.

Объединение аргументов POST и GET в WSGIRequest.REQUEST.¶

Уже настоятельно предлагалось использовать GET и POST вместо REQUEST, поскольку первые более явны. Свойство REQUEST устарело и будет удалено в Django 1.9.

Класс django.utils.datastructures.MergeDict¶

MergeDict существует в первую очередь для поддержки объединения аргументов POST и GET в свойство REQUEST в WSGIRequest. Чтобы объединить словари, используйте вместо этого dict.update(). Класс MergeDict устарел и будет удален в Django 1.9.

Коды языков zh-cn, zh-tw и fy-nl¶

Используемые в настоящее время языковые коды упрощенного китайского «zh-cn», традиционного китайского «zh-tw» и (западного) фризского «fy-nl» устарели и должны быть заменены языковыми кодами «zh-hans», «zh-hant» и «fy» соответственно. Если вы используете эти языковые коды, вам следует переименовать каталоги языковых стандартов и обновить настройки, чтобы отразить эти изменения. Устаревшие коды языков будут удалены в Django 1.9.

Функция django.utils.functional.memoize¶

Функция memoize устарела и должна быть заменена декоратором functools.lru_cache (доступен начиная с Python 3.2).

Django предоставляет резервную копию этого декоратора для более старых версий Python, и она доступна по адресу django.utils.lru_cache.lru_cache. Устаревшая функция будет удалена в Django 1.9.

Географические файлы Sitemap¶

Google прекратил поддержку формата Geo Sitemaps. Следовательно, поддержка Django для Geo Sitemaps устарела и будет удалена в Django 1.8.

Передача вызываемых аргументов в методы набора запросов¶

Вызываемые аргументы для наборов запросов были недокументированной и ненадежной функцией. Он устарел и будет удален в Django 1.9.

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

Настройка ADMIN_FOR¶

Функция ADMIN_FOR, являющаяся частью административной документации, была удалена. Вы можете удалить этот параметр из конфигурации по своему усмотрению.

SplitDateTimeWidget с DateTimeField¶

Поддержка SplitDateTimeWidget в DateTimeField устарела, вместо этого используйте SplitDateTimeWidget с SplitDateTimeField.

подтвердить¶

Команда управления validate устарела в пользу команды check.

django.core.management.BaseCommand¶

requires_model_validation устарел в пользу нового флага requires_system_checks. Если последний флаг отсутствует, то используется значение первого флага. Определение как requires_system_checks, так и requires_model_validation приводит к ошибке.

Метод check() заменил старый метод validate().

Валидаторы ModelAdmin¶

Атрибуты ModelAdmin.validator_class и default_validator_class устарели в пользу нового атрибутаchecks_class.

Метод ModelAdmin.validate() устарел в пользу метода ModelAdmin.check().

Модуль django.contrib.admin.validation устарел.

django.db.backends.DatabaseValidation.validate_field¶

Этот метод устарел в пользу нового метода check_field. Функциональность, требуемая для check_field(), такая же, как и для validate_field(), но формат вывода отличается. Сторонние базы данных, нуждающиеся в этой функции, должны обеспечивать реализацию check_field().

Загрузка тегов шаблонов ssi и url из библиотеки future¶

В Django 1.3 представлен синтаксис {% load ssi from Future %} и {% load url from Future %} для прямой совместимости тегов шаблонов ssi и url. Этот синтаксис устарел и будет удален в Django 1.9. Вы можете просто удалить {% load ... из будущих тегов %}.

django.utils.text.javascript_quote¶

javascript_quote() была недокументированной функцией, присутствующей в django.utils.text. Он использовался внутри представления javascript_catalog(), реализация которого была изменена для использования вместо него json.dumps(). Если вы полагались на эту функцию для обеспечения безопасного вывода ненадежных строк, вам следует использовать django.utils.html.escapejs или шаблонный фильтр escapejs. Если все, что вам нужно, это генерировать действительные строки JavaScript, вы можете просто использовать json.dumps().

fix_ampersands использует метод и фильтр шаблонов¶

Метод django.utils.html.fix_ampersands и шаблонный фильтр fix_ampersands устарели, поскольку экранирование амперсандов уже реализовано стандартными функциями экранирования HTML Django. Объединение этого с fix_ampersands приведет либо к двойному экранированию, либо, если вывод считается безопасным, к риску появления XSS-уязвимостей. Наряду с fix_ampersands устарела django.utils.html.clean_html — недокументированная функция, вызывающая fix_ampersands. Поскольку это ускоренное прекращение поддержки, fix_ampersands и clean_html будут удалены в Django 1.8.

Реорганизация настроек тестирования базы данных¶

Все настройки базы данных с префиксом TEST_ устарели в пользу записей в словаре TEST в настройках базы данных. Старые настройки будут поддерживаться до Django 1.9. Для обратной совместимости со старыми версиями Django вы можете определить обе версии настроек, если они совпадают.

Поддержка FastCGI¶

Поддержка FastCGI с помощью команды управления runfcgi будет удалена в Django 1.9. Пожалуйста, разверните свой проект с помощью WSGI.

Перемещены объекты в contrib.sites.¶

После рефакторинга загрузки приложения два объекта в django.contrib.sites.models пришлось переместить, поскольку они должны быть доступны без импорта django.contrib.sites.models, если django.contrib.sites не установлен. Импортируйте RequestSite из django.contrib.sites.requests и get_current_site() из django.contrib.sites.shortcuts. Старые места импорта будут работать до Django 1.9.

django.forms.forms.get_declared_fields()¶

Django больше не использует этот функционал внутри себя. Несмотря на то, что это частный API, он пройдет обычный цикл устаревания.

API поиска частных запросов¶

Частные API django.db.models.sql.where.WhereNode.make_atom() и django.db.models.sql.where.Constraint устарели в пользу нового API пользовательского поиска.