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

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

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

Миграции рассматриваются в their own documentation, но некоторые из ключевых особенностей таковы:

• 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 unless specifically requested.

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

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

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

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

К числу усовершенствований относятся:

• Приложения могут запускать код при запуске, до того, как Django сделает что-либо еще, с помощью метода ready() в их конфигурации.
• Ярлыки приложений правильно назначаются моделям, даже если они определены вне models.py. Вам больше не нужно явно задавать app_label.
• Можно полностью опустить models.py, если приложение не имеет никаких моделей.
• Приложения могут быть перемаркированы с помощью атрибута label в конфигурациях приложений, чтобы обойти конфликты меток.
• Название приложений может быть настроено в администраторе с помощью verbose_name конфигураций приложений.
• Администратор автоматически вызывает autodiscover() при запуске Django. Следовательно, вы можете удалить эту строку из вашего URLconf.
• Django импортирует все конфигурации и модели приложения сразу после его запуска, посредством детерминированного и простого процесса. Это должно облегчить диагностику проблем импорта, таких как зацикливание импорта.

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

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

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

• name: Имя атрибута поля в его родительской модели, или None, если оно не является частью модели
• path: Точечный, Python-путь к классу этого поля, включая имя класса.
• args: Позиционные аргументы, в виде списка
• kwargs: Аргументы ключевых слов, в виде диктанта

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

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

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

Это также означает, что все аргументы полей должны быть сериализуемыми; чтобы узнать, что мы считаем сериализуемым, и как сделать свои собственные классы сериализуемыми, прочитайте migration serialization documentation.

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

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

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

• Пользовательский QuerySet и его пользовательские методы были потеряны после первого вызова values() или values_list().
• При написании пользовательского Manager по-прежнему необходимо было возвращать пользовательский класс QuerySet, а все методы, которые были нужны на Manager, должны были быть проксированы на QuerySet. Весь процесс шел вразрез с принципом DRY.

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

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()

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

Теперь можно specify a custom manager при обходе обратной связи:

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()

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

Мы добавили новый System check framework для обнаружения распространенных проблем (например, недействительных моделей) и предоставления подсказок для их решения. Фреймворк является расширяемым, поэтому вы можете добавлять собственные проверки для своих приложений и библиотек.

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

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

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

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

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

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

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

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

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

До 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, которое извлекает год из значения поля. Преобразования позволяют создавать цепочки. После добавления преобразования year к DateField можно фильтровать преобразованное значение, например qs.filter(author__birthdate__year__lte=1981).

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

Улучшения в обработке ошибок Form¶

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

allow_syncdb / allow_migrate¶

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

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

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

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

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

Кроме того, как и остальной старый код Django syncdb, initial_data был запущен по пути депривации и будет удален в Django 1.9.

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

Django теперь требует, чтобы все классы Field и все аргументы их конструкторов были сериализуемыми. Если вы каким-либо образом измените сигнатуру конструктора в вашем пользовательском Field, вам нужно будет реализовать метод deconstruct(); мы расширили документацию по пользовательским полям с помощью instructions on implementing this method.

Требование, чтобы все аргументы поля были serializable означает, что любые экземпляры пользовательских классов, передаваемые в конструкторы Field - например, такие вещи, как пользовательские подклассы Storage - должны иметь deconstruct method defined on them as well, хотя 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, когда он получает в качестве аргумента контейнер ошибок (например, list или ErrorList):

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

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

Кроме того, если вы напрямую присвоили возвращаемое значение update_error_dict() в Form._errors, вы можете случайно добавить экземпляры list туда, где ожидаются экземпляры ErrorList. Это проблема, потому что в отличие от простого list, 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 в отношении ошибок pickle¶

В предыдущих версиях 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.syndication.

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 выполняют вложенные запросы при фильтрации, что может быть или не быть проблемой в зависимости от вашей базы данных и самих данных. Более подробную информацию смотрите в this note.

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

Исторически сложилось так, что административный сайт 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 autocommit, в проект, который работает без них; и далее, такие ошибки могут проявляться как ошибки повреждения данных. Это также было сделано в Django 1.6.3.

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

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

В app-loading refactor устарело использование моделей из приложений, которые не являются частью настройки 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 стал менее мощным, но в то же время в нем меньше магии.

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

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

• Упорядочение полей Form по умолчанию в случае наследования было изменено в соответствии с обычным 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_related('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 теперь поддерживает необязательный аргумент related_query_name. Установка related_query_name добавляет отношение от связанного объекта обратно к типу содержимого для фильтрации, упорядочивания и других операций запроса.

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

• Как часть System check framework, fields, models, and model managers все реализуют метод check(), который регистрируется в фреймворке проверки. Если у вас есть существующий метод с именем check() на одном из этих объектов, вам нужно будет переименовать его.

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

• Команды управления 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.caches.

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, и повторно поднимает 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()), были удалены. Если вы использовали эти методы для изменения структур, таких как поля формы, то теперь вы должны рассматривать эти OrderedDicts как неизменяемые объекты и переопределять их для изменения их содержимого.

Например, вы можете переопределить 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¶

Команда 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.

Geo Sitemaps¶

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

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

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

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

ADMIN_FOR установка¶

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

SplitDateTimeWidget с DateTimeField¶

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

validate¶

Команда управления 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 ... from future %}.

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 устарели в пользу новых custom lookups API.