Model._meta API¶

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

Объект Model._meta был частью Django со времен Magic Removal до версии 0.96 — он просто не был официальным стабильным API. Признавая это, мы постарались сохранить обратную совместимость со старой конечной точкой API, где это возможно. Однако конечные точки API, которые не являются частью нового официального API, устарели и в конечном итоге будут удалены.

Несколько шаблонизаторов¶

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

Улучшения безопасности¶

Некоторые функции django-secure сторонней библиотеки были интегрированы в Django. django.middleware.security.SecurityMiddleware обеспечивает несколько улучшений безопасности цикла запрос/ответ. Новая опция check --deploy позволяет вам проверить файл производственных настроек на предмет способов повышения безопасности вашего сайта.

Новые специальные функции PostgreSQL.¶

В Django теперь есть модуль с расширениями для специфических функций PostgreSQL, таких как ArrayField, HStoreField, Поля диапазона и unaccent поиск. Полное описание функций доступно в документации.

Новые типы данных¶

• В Django теперь есть UUIDField для хранения универсально уникальных идентификаторов. Он хранится как собственный тип данных uuid в PostgreSQL и как символьное поле фиксированной длины в других бэкендах. Существует соответствующее поле формы.

• В Django теперь есть DurationField для хранения периодов времени, смоделированный в Python с помощью timedelta. Он хранится в родном типе данных «интервал» в PostgreSQL, как «ИНТЕРВАЛ ДЕНЬ(9) ТО СЕКУНД(6)» в Oracle и как «бигинта» микросекунд в других бэкендах. Арифметика, связанная с датой и временем, также была улучшена на всех серверах. Существует соответствующее поле формы.

Выражения запроса, условные выражения и функции базы данных¶

Выражения запроса позволяют создавать, настраивать и составлять сложные выражения SQL. Это позволило аннотациям принимать выражения, отличные от агрегатов. Агрегаты теперь могут ссылаться на несколько полей, а также выполнять арифметические действия, аналогично объектам F(). order_by() также получил возможность принимать выражения.

Условные выражения позволяют использовать логику if … elif … else в запросах.

Коллекция функций базы данных также включена в состав таких функций, как Coalesce, Concat и Substr.

Настройка данных TestCase¶

TestCase был реорганизован, чтобы обеспечить инициализацию данных на уровне класса с использованием транзакций и точек сохранения. Серверные части баз данных, которые не поддерживают транзакции, такие как MySQL с механизмом хранения MyISAM, по-прежнему смогут выполнять эти тесты, но не получат выгоды от улучшений. Тесты теперь выполняются в двух вложенных блоках atomic(): один для всего класса и один для каждого теста.

• Метод класса TestCase.setUpTestData() добавляет возможность настройки тестовых данных на уровне класса. Использование этого метода может ускорить тестирование по сравнению с использованием setUp().

• Загрузка фикстуры в TestCase теперь выполняется один раз для всего TestCase.

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

Операции со связанными объектами выполняются в транзакции.¶

Некоторые операции над связанными объектами, такие как add() или прямое присвоение, выполняли несколько запросов на изменение данных, не заключая их в транзакции. Чтобы снизить риск повреждения данных, все методы изменения данных, которые влияют на несколько связанных объектов (т. е. add(), remove(), clear() и прямое присвоение), теперь выполняют свои запросы на изменение данных из транзакции, при условии, что ваша база данных поддерживает транзакции.

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

Назначение несохраненных объектов отношениям вызывает ошибку¶

>>> book = Book.objects.create(name="Django")
>>> book.author = Author(name="John")
>>> book.save()
Traceback (most recent call last):
...
ValueError: save() prohibited to prevent data loss due to unsaved related object 'author'.

Присвоение несохраненных объектов ForeignKey, GenericForeignKey и OneToOneField теперь вызывает ошибку ValueError.

Раньше назначение несохраненного объекта игнорировалось. Например:

>>> book = Book.objects.create(name="Django")
>>> book.author = Author(name="John")
>>> book.author.save()
>>> book.save()

>>> Book.objects.get(name="Django")
>>> book.author
>>>

Теперь будет выдана ошибка, чтобы предотвратить потерю данных:

>>> book.author = Author(name="john")
Traceback (most recent call last):
...
ValueError: Cannot assign "<Author: John>": "Author" instance isn't saved in the database.

Если вам требуется разрешить назначение несохраненных экземпляров (старое поведение) и вас не беспокоит возможность потери данных (например, вы никогда не сохраняете объекты в базе данных), вы можете отключить эту проверку с помощью атрибута ForeignKey.allow_unsaved_instance_assignment. (Этот атрибут был удален в версии 1.8.4, поскольку он больше не актуален.)

Команды управления, которые принимают только позиционные аргументы¶

Если вы написали специальную команду управления, которая принимает только позиционные аргументы, и не указали командную переменную args, вы можете получить сообщение об ошибке типа Ошибка: нераспознанные аргументы: ..., поскольку синтаксический анализ переменных теперь основан на argparse, который неявно не принимает позиционные аргументы. Вы можете сделать свою команду обратно совместимой, просто установив переменную класса args. Однако, если вам не нужно поддерживать совместимость со старыми версиями Django, лучше реализовать новый метод add_arguments(), как описано в Реализация собственных команд django-admin.

Пользовательские аргументы команды управления тестированием с помощью средства запуска тестов¶

Изменился метод добавления пользовательских аргументов к команде управления «test» через средство запуска тестов. Раньше вы могли предоставить переменную класса option_list в программе запуска тестов, чтобы добавить больше аргументов (как в optparse). Теперь, чтобы реализовать то же поведение, вам нужно создать метод класса add_arguments(cls, parser) в средстве запуска тестов и вызвать parser.add_argument для добавления любых пользовательских аргументов, поскольку синтаксический анализатор теперь является экземпляром argparse.ArgumentParser.

Проверка модели гарантирует, что автоматически создаваемые имена столбцов находятся в пределах, установленных базой данных.¶

Имя поля, длина которого превышает длину имени столбца, поддерживаемого базой данных, может создать проблемы. Например, в MySQL вы получите исключение при попытке создать столбец, а в PostgreSQL имя столбца усекается базой данных (вы можете увидеть предупреждение в журналах PostgreSQL).

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

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

Проверка также применяется к столбцам, созданным в неявной модели ManyToManyField.through. Если вы столкнулись с проблемой, используйте through, чтобы создать явную модель, а затем при необходимости укажите db_column для ее столбца(ов).

Поиск отношений запроса теперь проверяет типы объектов.¶

При запросе поиска модели теперь проверяется, имеет ли переданный объект правильный тип, и в противном случае выдается ValueError. Раньше Django не заботилось о том, правильный ли тип объекта; он просто использовал атрибут связанного поля объекта (например, id) для поиска. Теперь возникает ошибка, чтобы предотвратить неправильный поиск:

>>> book = Book.objects.create(name="Django")
>>> book = Book.objects.filter(author=book)
Traceback (most recent call last):
...
ValueError: Cannot query "<Book: Django>": Must be "Author" instance.

select_related() теперь проверяет заданные поля¶

select_related() теперь проверяет, что данные поля действительно существуют. Раньше несуществующие поля молча игнорировались. Теперь возникает ошибка:

>>> book = Book.objects.select_related("nonexistent_field")
Traceback (most recent call last):
...
FieldError: Invalid field name(s) given in select_related: 'nonexistent_field'

Проверка также гарантирует, что данное поле является реляционным:

>>> book = Book.objects.select_related("name")
Traceback (most recent call last):
...
FieldError: Non-relational field given in select_related: 'name'

Значение по умолчанию EmailField.max_length увеличено до 254.¶

Старая 75-символьная max_length по умолчанию не могла хранить все возможные адреса электронной почты, соответствующие RFC3696/5321. Чтобы сохранить все возможные действительные адреса электронной почты, длина max_length была увеличена до 254 символов. Вам нужно будет сгенерировать и применить миграцию базы данных для затронутых вами моделей (или добавить max_length=75, если вы хотите сохранить длину текущих полей). Включена миграция для django.contrib.auth.models.User.email.

Поддержка версий PostgreSQL старше 9.0.¶

Окончание периодов поддержки исходных версий PostgreSQL 8.4 наступило в июле 2014 года. Как следствие, Django 1.8 устанавливает 9.0 как минимальную официально поддерживаемую версию PostgreSQL.

Это также включает прекращение поддержки PostGIS 1.3 и 1.4, поскольку эти версии не поддерживаются в версиях PostgreSQL позже 8.4.

Django также теперь требует использования Psycopg2 версии 2.4.5 или выше (или 2.5+, если вы хотите использовать django.contrib.postgres).

Поддержка версий MySQL старше 5.5.¶

Окончание периодов поддержки исходных версий было достигнуто в январе 2012 года для MySQL 5.0 и в декабре 2013 года для MySQL 5.1. Как следствие, Django 1.8 устанавливает 5.5 в качестве минимальной официально поддерживаемой версии MySQL.

Поддержка версий Oracle старше 11.1.¶

Окончание периодов поддержки исходного кода было достигнуто в июле 2010 года для Oracle 9.2, в январе 2012 года для Oracle 10.1 и в июле 2013 года для Oracle 10.2. Как следствие, Django 1.8 устанавливает 11.1 как минимальную официально поддерживаемую версию Oracle.

Определенные привилегии, используемые вместо ролей для тестов в Oracle¶

Более ранние версии Django предоставили роли CONNECT и RESOURCE тестовому пользователю в Oracle. Эти роли устарели, поэтому Django 1.8 вместо них использует определенные базовые привилегии. Это изменяет привилегии, необходимые основному пользователю для запуска тестов (если проект не настроен так, чтобы не создавать тестового пользователя). Точные привилегии, необходимые сейчас, подробно описаны в Oracle Notes.

AbstractUser.last_login допускает нулевые значения.¶

Поле AbstractUser.last_login теперь допускает нулевые значения. Раньше по умолчанию использовалось время создания пользователя, что вводило в заблуждение, если пользователь никогда не входил в систему. Если вы используете пользователя по умолчанию (django.contrib.auth.models.User), запустите миграцию базы данных, включенную в contrib.auth.

Если вы используете пользовательскую модель, унаследованную от AbstractUser, вам нужно будет запустить makemigrations и создать миграцию для вашего приложения, содержащего эту модель. Кроме того, если вы хотите установить last_login в NULL для пользователей, которые еще не вошли в систему, вы можете запустить этот запрос:

from django.db import models
from django.contrib.auth import get_user_model
from django.contrib.auth.models import AbstractBaseUser

UserModel = get_user_model()
if issubclass(UserModel, AbstractBaseUser):
    UserModel._default_manager.filter(last_login=models.F("date_joined")).update(
        last_login=None
    )

django.contrib.gis¶

• Поддержка GEOS 3.1 и GDAL 1.6 прекращена.

• Поддержка SpatiaLite < 2.4 прекращена.

• Поиски, специфичные для ГИС, были переработаны для использования API django.db.models.Lookup.

• Представление str объектов GEOSGeometry по умолчанию было изменено с формата WKT на формат EWKT (включая SRID). Поскольку это представление используется в структуре сериализации, это означает, что выходные данные dumpdata теперь будут содержать значение SRID геометрических объектов.

Приоритет контекстных процессоров для «TemplateResponse» приведен в соответствие с «render».¶

Конструктор TemplateResponse предназначен для замены функции render(). Однако у него была небольшая несовместимость: для «TemplateResponse» контекстные данные из переданного контекстного словаря могли быть затенены контекстными данными, возвращаемыми от контекстных процессоров, тогда как для «render» все было наоборот. Это была ошибка, и поведение render является более подходящим, поскольку оно позволяет локально переопределять глобально определенные контекстные процессоры в представлении. Если вы полагались на тот факт, что данные контекста в шаблоне «TemplateResponse» могут быть переопределены с помощью процессора контекста, вам нужно будет изменить свой код.

Переопределение setUpClass/tearDownClass в тестовых примерах¶

Декораторы override_settings() и modify_settings() теперь действуют на уровне класса, когда используются в качестве декораторов классов. Как следствие, при переопределении setUpClass() или tearDownClass() всегда должна вызываться реализация super.

Удаление django.contrib.formtools¶

Приложение formtools contrib было перенесено в отдельный пакет, а соответствующие страницы документации были обновлены или удалены.

Новый пакет доступен на GitHub и PyPI.

Перезагрузка соединения с базой данных между тестами¶

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

Очистка пространства имен django.template.¶

Если вы полагались на частные API, представленные в модуле django.template, возможно, вам придется вместо этого импортировать их из django.template.base.

Также были удалены частные API django.template.base.compile_string(), django.template.loader.find_template() и django.template.loader.get_template_from_string().

Атрибут model в отношениях частной модели¶

В более ранних версиях Django, в модели с обратным отношением внешнего ключа (например), model._meta.get_all_related_objects() возвращала отношение как django.db.models.related.RelatedObject с атрибутом model, установленным для источника отношения. Теперь этот метод возвращает связь как «django.db.models.fields.related.ManyToOneRel» (частный API «RelatedObject» был удален), а атрибуту «model» присвоена цель связи, а не источник. Вместо этого исходная модель доступна по атрибуту linked_model.

Рассмотрим этот пример из руководства по Django 1.8:

>>> p = Poll.objects.get(pk=1)
>>> p._meta.get_all_related_objects()
[<ManyToOneRel: polls.choice>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Poll'>
>>> p._meta.get_all_related_objects()[0].related_model
<class 'polls.models.Choice'>

и сравните его с поведением в старых версиях:

>>> p._meta.get_all_related_objects()
[<RelatedObject: polls:choice related to poll>]
>>> p._meta.get_all_related_objects()[0].model
<class 'polls.models.Choice'>

Чтобы получить доступ к исходной модели, вы можете использовать подобный шаблон для написания кода, который будет работать как с Django 1.8, так и с более ранними версиями:

for relation in opts.get_all_related_objects():
    to_model = getattr(relation, "related_model", relation.model)

Также обратите внимание, что get_all_related_objects() устарел в версии 1.8.

Серверный API базы данных¶

Следующие изменения в API серверной части базы данных задокументированы, чтобы помочь тем, кто пишет сторонние серверные части, в обновлении своего кода:

• Классы BaseDatabaseXXX были перенесены в django.db.backends.base. Пожалуйста, импортируйте их из новых мест:

  from django.db.backends.base.base import BaseDatabaseWrapper
  from django.db.backends.base.client import BaseDatabaseClient
  from django.db.backends.base.creation import BaseDatabaseCreation
  from django.db.backends.base.features import BaseDatabaseFeatures
  from django.db.backends.base.introspection import BaseDatabaseIntrospection
  from django.db.backends.base.introspection import FieldInfo, TableInfo
  from django.db.backends.base.operations import BaseDatabaseOperations
  from django.db.backends.base.schema import BaseDatabaseSchemaEditor
  from django.db.backends.base.validation import BaseDatabaseValidation
  

• Атрибуты data_types, data_types_suffix и data_type_check_constraints перемещены из класса DatabaseCreation в DatabaseWrapper.

• Метод SQLCompiler.as_sql() теперь принимает параметр подзапроса (#24164).

• Метод BaseDatabaseOperations.date_interval_sql() теперь принимает только параметр timedelta.

django.contrib.admin¶

• AdminSite больше не принимает аргумент app_name, а его атрибут app_name был удален. Имя приложения всегда admin (в отличие от имени экземпляра, которое вы все равно можете настроить с помощью AdminSite(name="...").

• Метод ModelAdmin.get_object() (частный API) теперь принимает третий аргумент с именем from_field, чтобы указать, какое поле должно соответствовать предоставленному object_id.

• Метод ModelAdmin.response_delete() теперь принимает второй аргумент с именем obj_id, который представляет собой сериализованный идентификатор, используемый для получения объекта перед удалением.

Автоэкранирование функций по умолчанию в django.template.defaultfilters¶

Чтобы сделать встроенные фильтры шаблонов, которые выводят HTML «безопасными по умолчанию» при вызове их в коде Python, следующие функции в django.template.defaultfilters были изменены, чтобы автоматически экранировать их входное значение:

• присоединяйся

• разрывы строкbr

• linebreaks_filter

• номера строк

• неупорядоченный_список

• urlize

• urlizetrnc

Вы можете вернуться к старому поведению, указав autoescape=False, если вы передаете доверенный контент. Это изменение не влияет на использование соответствующих фильтров в шаблонах.

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

• connections.queries теперь является атрибутом только для чтения.

• Соединения с базой данных считаются равными, только если они являются одним и тем же объектом. Они больше не подлежат хешированию.

• GZipMiddleware используется для отключения сжатия для некоторых типов контента, когда запрос поступает из Internet Explorer, чтобы обойти ошибку в IE6 и более ранних версиях. Такое поведение может повлиять на производительность в IE7 и более поздних версиях. Оно было удалено.

• URLField.to_python больше не добавляет косую черту в конце URL-адресов без путей.

• Фильтр шаблона length теперь возвращает 0 для неопределенной переменной, а не пустую строку.

• ForeignKey.default_error_message['invalid'] изменен с '%(model)s экземпляр с pk %(pk)r не существует.' на '%(model)s экземпляр с %(field)s %(value)r не существует.' Если вы используете это сообщение в своем собственном коде, обновите список интерполируемых параметров. Внутри Django продолжит предоставлять параметр pk в params для обратной совместимости.

• UserCreationForm.error_messages['duulate_username'] больше не используется. Если вы хотите настроить это сообщение об ошибке, переопределите его в форме, используя ключ unique' в Meta.error_messages['username'] или, если у вас есть настраиваемое поле формы для 'username', используя 'unique' ключ в его error_messages аргумент.

• Блок usertools в шаблоне base.html django.contrib.admin теперь требует установки контекстной переменной has_permission. Если у вас есть пользовательские представления администратора, использующие этот шаблон, обновите их, чтобы они передавали AdminSite.has_permission() в качестве значения этой новой переменной, или просто включите AdminSite.each_context(request) в контекст.

• В виджет ClearableFileInput были внесены внутренние изменения, позволяющие расширить возможности настройки. Недокументированный атрибут url_markup_template был удален в пользу template_with_initial.

• Для совместимости с другими крупными поставщиками в локали en_GB теперь первым днем ​​недели является понедельник.

• Секунды были удалены из всех локалей, в которых они были указаны в TIME_FORMAT, DATETIME_FORMAT или SHORT_DATETIME_FORMAT.

• Максимальный размер тестового табличного пространства Oracle по умолчанию увеличен с 300 МБ (или 200 МБ до версии 1.7.2) до 500 МБ.

• reverse() и reverse_lazy() теперь возвращают строки Unicode вместо байтовых строк.

• Оболочка CacheClass была удалена из всех серверов кэширования. Эти псевдонимы были предоставлены для обратной совместимости с Django 1.3. Если вы все еще используете их, обновите свой проект, чтобы использовать реальное имя класса, указанное в ключе BACKEND настройки CACHES.

• По умолчанию call_command() теперь всегда пропускает структуру проверки (если вы не передадите skip_checks=False).

• При переборе строк File теперь использует универсальные символы новой строки. Следующие символы считаются завершением строки: соглашение о конце строки Unix '\n', соглашение Windows '\r\n' и старое соглашение Macintosh '\r'.

• Серверные части кэша Memcached MemcachedCache и PyLibMCCache удалят ключ в случае сбоя set(). Это необходимо для того, чтобы хранилище сеансов cache_db всегда извлекало самые последние данные сеанса.

• Частные API override_template_loaders и override_with_test_loader в django.test.utils были удалены. Вместо этого переопределите TEMPLATES с помощью override_settings.

• Предупреждения из базы данных MySQL больше не преобразуются в исключения, если для DEBUG установлено значение True.

• HttpRequest теперь имеет упрощенный repr (например, <WSGIRequest: GET '/somepath/'>). Это не изменит поведение класса SafeExceptionReporterFilter.

• Представления на основе классов, использующие ModelFormMixin, вызовут исключение ImproperlyConfigured, если указаны оба атрибута fields и form_class. Раньше поля игнорировались.

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

• Переводимые строки, установленные в качестве параметра поля default, позже преобразуются в конкретные строки, поэтому тип возвращаемого значения Field.get_default() в некоторых случаях отличается. Значения по умолчанию, являющиеся результатом вызываемого объекта, не изменяются.

• GenericIPAddressField.empty_strings_allowed теперь имеет значение False. Серверные части базы данных, которые интерпретируют пустые строки как нулевые (только Oracle среди серверных частей, включенных в Django), больше не будут преобразовывать нулевые значения обратно в пустую строку. Это согласуется с другими бэкэндами.

• Когда атрибут BaseCommand.leave_locale_alone имеет значение False, переводы теперь деактивируются вместо принудительного использования локали «en-us». В случае, если ваши модели содержали неанглийские строки и вы рассчитывали на активацию английских переводов в командах управления, этого больше не произойдет. Возможно, новые миграции базы данных создаются (один раз) после перехода на версию 1.8.

• django.utils.translation.get_language() теперь возвращает None вместо LANGUAGE_CODE, когда переводы временно отключены.

• Если для определенного литерала не существует перевода, резервный вариант теперь берется из языка LANGUAGE_CODE (а не из непереведенного сообщения msgid).

• Поле name в django.contrib.contenttypes.models.ContentType было удалено в ходе миграции и заменено свойством. Это означает, что больше невозможно запрашивать или фильтровать ContentType по этому полю.

  Будьте осторожны, если вы обновитесь до Django 1.8 и пропустите Django 1.7. Если вы запустите manage.pymigrate --fake, эта миграция будет пропущена, и вы увидите исключение RuntimeError: Ошибка создания новых типов контента., поскольку столбец name не будет удален из базы данных. Вместо этого используйте manage.pymigrate --fake-initial, чтобы имитировать только первоначальную миграцию.

• Новая опция migrate --fake-initial позволяет имитировать первоначальные миграции. В версии 1.7 первоначальные миграции всегда автоматически подделывались, если все таблицы, созданные при первоначальной миграции, уже существовали.

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

Выбранные методы в django.db.models.options.Options¶

В рамках формализации API Model._meta (из класса django.db.models.options.Options) ряд методов объявлены устаревшими и будут удалены в Django 1.10:

• get_all_field_names()

• get_all_related_objects()

• get_all_related_objects_with_model()

• get_all_lated_many_to_many_objects()

• get_all_lated_m2m_objects_with_model()

• get_concrete_fields_with_model()

• get_field_by_name()

• get_fields_with_model()

• get_m2m_with_model()

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

В Django 1.6 представлен синтаксис {% загрузки цикла из будущего %} и {% загрузки firstof из будущего %} для прямой совместимости тегов шаблонов cycle и firstof. Этот синтаксис устарел и будет удален в Django 1.10. Вы можете просто удалить {% load ... из будущих тегов %}.

django.conf.urls.patterns()¶

В старые времена Django поощрялось ссылаться на представления как на строки в urlpatterns:

urlpatterns = patterns(
    "",
    url("^$", "myapp.views.myview"),
)

и Django волшебным образом импортировал myapp.views.myview внутрь и превратил строку в реальную ссылку на функцию. Чтобы уменьшить повторение при ссылке на множество представлений из одного и того же модуля, функцияpatterns() принимает обязательный начальный аргумент prefix, который добавляется ко всем представлениям как строкам в этом наборе urlpatterns:

urlpatterns = patterns(
    "myapp.views",
    url("^$", "myview"),
    url("^other/$", "otherview"),
)

В современную эпоху мы обновили руководство, чтобы вместо этого рекомендовать импортировать модуль представлений и напрямую ссылаться на ваши функции представления (или классы). Это имеет ряд преимуществ, и все они вытекают из того факта, что мы используем обычный Python вместо «Django String Magic»: ошибки при неправильном вводе имени представления менее заметны, IDE могут помочь с автодополнением имен представления и т. д.

Таким образом, в наши дни приведенное выше использование префикса arg с гораздо большей вероятностью будет записано (и лучше записано) как:

from myapp import views

urlpatterns = patterns(
    "",
    url("^$", views.myview),
    url("^other/$", views.otherview),
)

Таким образом, patterns() не приносит никакой пользы и является бременем при обучении новых пользователей (отвечая на вопрос новичка: «Зачем мне нужна эта пустая строка в качестве первого аргумента patterns()??). По этим причинам мы отказываемся от него. Обновить ваш код так же просто, как убедиться, что urlpatterns представляет собой список экземпляров django.conf.urls.url(). Например:

from django.conf.urls import url
from myapp import views

urlpatterns = [
    url("^$", views.myview),
    url("^other/$", views.otherview),
]

Передача строки как view в django.conf.urls.url()¶

Что касается предыдущего пункта, ссылка на представления как на строки в функции url() устарела. Вместо этого передайте вызываемое представление, как описано в предыдущем разделе.

Настройки, связанные с шаблоном¶

В результате рефакторинга нескольких шаблонизаторов некоторые настройки устарели в пользу TEMPLATES:

• ALLOWED_INCLUDE_ROOTS

• TEMPLATE_CONTEXT_PROCESSORS

• TEMPLATE_DEBUG

• TEMPLATE_DIRS

• TEMPLATE_LOADERS

• TEMPLATE_STRING_IF_INVALID

django.core.context_processors¶

Встроенные процессоры контекста шаблона были перенесены в django.template.context_processors.

django.test.SimpleTestCase.urls¶

Атрибут SimpleTestCase.urls для указания конфигурации URLconf в тестах устарел и будет удален в Django 1.10. Вместо этого используйте @override_settings(ROOT_URLCONF=...).

prefix аргумент для i18n_patterns()¶

Что касается предыдущего пункта, аргумент prefix для django.conf.urls.i18n.i18n_patterns() устарел. Вместо этого просто передайте список экземпляров django.conf.urls.url().

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

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

Передача пунктирного пути в reverse() и url¶

Изменение URL-адресов по пути Python — дорогостоящая операция, поскольку она приводит к импорту реверсируемого пути. Такое поведение также привело к «проблеме безопасности». Вместо этого используйте шаблоны именованных URL-адресов для реверса.

Если вы используете django.contrib.sitemaps, добавьте аргумент name к url, который ссылается на django.contrib.sitemaps.views.sitemap():

from django.contrib.sitemaps.views import sitemap

url(
    r"^sitemap\.xml$",
    sitemap,
    {"sitemaps": sitemaps},
    name="django.contrib.sitemaps.views.sitemap",
)

для обеспечения совместимости при удалении пути Python в Django 1.10.

Аналогично для карт сайта ГИС добавьте name='django.contrib.gis.sitemaps.views.kml' или name='django.contrib.gis.sitemaps.views.kmz'.

Если вы используете путь Python для настройки LOGIN_URL или LOGIN_REDIRECT_URL, используйте вместо этого имя url().

Агрегатные методы и модули¶

Модули django.db.models.sql.aggregates и django.contrib.gis.db.models.sql.aggregates (оба являются частными API) устарели, поскольку django.db.models.aggregates и django.contrib.gis.db.models.aggregates теперь также отвечают за генерацию SQL. Старые модули будут удалены в Django 1.10.

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

Следующие методы и свойства django.db.models.sql.query.Query также устарели, а прокладки обратной совместимости будут удалены в Django 1.10:

• Query.aggregates заменен на аннотации.

• Query.aggregate_select заменен на annotation_select.

• Query.add_aggregate() заменен на add_annotation().

• Query.set_aggregate_mask() заменен на set_annotation_mask().

• Query.append_aggregate_mask() заменен на append_annotation_mask().

Расширение аргументов команды управления через Command.option_list¶

Команды управления теперь используют argparse вместо optparse для анализа аргументов командной строки, передаваемых командам. Это также означает, что изменился способ добавления пользовательских аргументов к командам: вместо расширения списка классов option_list вам теперь следует переопределить метод add_arguments() и добавлять аргументы через argparse.add_argument(). См. этот пример для более подробной информации.

django.core.management.NoArgsCommand¶

Класс NoArgsCommand устарел и будет удален в Django 1.10. Вместо этого используйте BaseCommand, который по умолчанию не принимает аргументов.

Перечисление всех миграций в проекте¶

Опция --list команды управления migrate устарела и будет удалена в Django 1.10. Вместо этого используйте showmigrations.

Опция cache_choices для ModelChoiceField и ModelMultipleChoiceField¶

ModelChoiceField и ModelMultipleChoiceField использовали недокументированную, непроверенную опцию cache_choices. Этот кэшированный набор запросов между несколькими визуализациями одного и того же объекта «Форма». Эта опция подлежит ускоренному прекращению поддержки и будет удалена в Django 1.9.

django.template.resolve_variable()¶

В течение некоторого времени функция была неофициально помечена как «Устаревшая». Замените resolve_variable(path, context) на django.template.Variable(path).resolve(context).

django.contrib.webdesign¶

Он предоставил тег шаблона lorem, который теперь включен во встроенные теги. Просто удалите 'django.contrib.webdesign' из :setting:INSTALLED_APPS` и ``{% load webdesign %} из ваших шаблонов.

Аргумент error_message для django.forms.RegexField¶

Он обеспечивал обратную совместимость с кодом версий до 1.0, но его функциональность избыточна. Вместо этого используйте Field.error_messages['invalid'].

Старый синтаксис unordered_list¶

Старый (до версии 1.0), более строгий и подробный формат ввода для фильтра шаблона unordered_list устарел:

["States", [["Kansas", [["Lawrence", []], ["Topeka", []]]], ["Illinois", []]]]

Используя новый синтаксис, это будет:

["States", ["Kansas", ["Lawrence", "Topeka"], "Illinois"]]

django.forms.Field._has_changed()¶

Переименуйте этот метод в has_changed(), удалив начальное подчеркивание. Старое имя будет работать до Django 1.10.

Фильтр шаблонов django.utils.html.remove_tags() и removetags¶

django.utils.html.remove_tags(), а также фильтр шаблонов removetags устарели, поскольку они не могут гарантировать безопасный вывод. Их существование, вероятно, приведет к их использованию в контекстах, чувствительных к безопасности, где они на самом деле небезопасны.

Неиспользуемая и недокументированная функция django.utils.html.strip_entities() также признана устаревшей.

Аргумент is_admin_site для django.contrib.auth.views.password_reset()¶

Это устаревший вариант, который больше не нужен.

База Подполя¶

django.db.models.fields.subclassing.SubfieldBase устарел и будет удален в Django 1.10. Исторически он использовался для обработки полей, где при загрузке из базы данных требовалось преобразование типов, но не использовался в вызовах .values() или в агрегатах. Он был заменен на from_db_value().

Новый подход не вызывает метод to_python() при назначении, как это было в случае с SubfieldBase``. Если вам нужно такое поведение, переопределите класс Creator из исходного кода Django <https://github.com/django/django/blob/stable/1.8.x/django/db/models/fields/subclassing.py#L31-L44>`_ в своем проекте.

django.utils.checksums¶

Модуль django.utils.checksums устарел и будет удален в Django 1.10. Предоставляемая им функциональность (проверка контрольной суммы с использованием алгоритма Луна) была недокументирована и не использовалась в Django. Модуль перенесен в пакет django-localflavor (версия 1.1+).

InlineAdminForm.original_content_type_id¶

Атрибут original_content_type_id в InlineAdminForm устарел и будет удален в Django 1.10. Исторически он использовался для создания URL-адреса «просмотра на сайте». Этот URL-адрес теперь доступен с помощью атрибута формы absolute_url.

Аргумент form_class django.views.generic.edit.FormMixin.get_form()¶

Подклассы FormMixin, которые переопределяют метод get_form(), должны обязательно предоставлять значение по умолчанию для аргумента form_class, поскольку теперь он не является обязательным.

Шаблоны рендеринга, загруженные get_template() с Context¶

Тип возвращаемого значения get_template() изменился в Django 1.8: вместо django.template.Template он возвращает экземпляр Template, точный тип которого зависит от того, какой сервер его загрузил.

Оба класса предоставляют метод render(), однако первый принимает django.template.Context в качестве аргумента, а второй ожидает dict. Это изменение применяется через прекращение поддержки шаблонов Django.

Все это также относится и к select_template().

Классы Template и Context в ответах шаблона¶

Некоторые методы SimpleTemplateResponse и TemplateResponse принимают объекты django.template.Context и django.template.Template в качестве аргументов. Теперь они должны получить dict и объекты шаблонов, зависящие от серверной части соответственно.

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

Дополнительную информацию можно найти в документации API шаблона ответа.

Аргумент current_app API, связанных с шаблоном¶

Следующие функции и классы больше не будут принимать параметр current_app для установки пространства имен URL в Django 1.10:

• django.shortcuts.render()

• django.template.Context()

• django.template.RequestContext()

• django.template.response.TemplateResponse()

Вместо этого установите request.current_app, где request — это первый аргумент этих функций или классов. Если вы используете простой «Контекст», используйте вместо него «RequestContext».

Аргументы dictionary и context_instance функций рендеринга¶

Следующие функции больше не будут принимать параметры dictionary и context_instance в Django 1.10:

• django.shortcuts.render()

• django.shortcuts.render_to_response()

• django.template.loader.render_to_string()

Вместо этого используйте параметр context. Когда словарь передается в качестве позиционного аргумента (это наиболее распространенная идиома), никаких изменений не требуется.

Если вы передаете Context в context_instance, вместо этого передайте dict в параметре context. Если вы передаете RequestContext, передайте запрос отдельно в параметре request.

dirs аргумент функций поиска шаблонов¶

Следующие функции больше не будут принимать параметр dirs для переопределения TEMPLATE_DIRS в Django 1.10:

• django.template.loader.get_template()

• django.template.loader.select_template()

• django.shortcuts.render()

• django.shortcuts.render_to_response()

Этот параметр не работал одинаково в разных загрузчиках шаблонов и не работал для включенных шаблонов.

django.template.loader.BaseLoader¶

django.template.loader.BaseLoader был переименован в django.template.loaders.base.Loader. Если вы написали собственный загрузчик шаблонов, который наследует BaseLoader, вместо этого вы должны наследовать Loader.

django.test.utils.TestTemplateLoader¶

Частный API django.test.utils.TestTemplateLoader устарел в пользу django.template.loaders.locmem.Loader и будет удален в Django 1.9.

Поддержка аргумента max_length в пользовательских классах Storage.¶

Подклассы Storage должны добавлять max_length=None в качестве параметра к get_available_name() и/или save(), если они переопределяют любой метод. Поддержка хранилищ, которые не принимают этот аргумент, будет удалена в Django 1.10.

qn заменен на компилятор¶

В предыдущих версиях Django различные внутренние методы ORM (в основном методы as_sql) принимали аргумент qn (для «имя кавычки»), который был ссылкой на функцию, которая заключала в кавычки идентификаторы для отправки в базу данных. В Django 1.8 этот аргумент был переименован в compiler и теперь является полноценным экземпляром SQLCompiler. Для обеспечения обратной совместимости вызов экземпляра SQLCompiler выполняет то же самое заключение имени в кавычки, что и функция qn. Однако эта оболочка обратной совместимости немедленно устарела: вам следует переименовать аргументы qn в compiler и вызвать compiler.quote_name_unless_alias(...) там, где вы ранее вызывали qn(...).

Значение по умолчанию RedirectView.permanent¶

Значение по умолчанию атрибута RedirectView.permanent изменится с True на False в Django 1.9.

Использование AuthenticationMiddleware без SessionAuthenticationMiddleware¶

django.contrib.auth.middleware.SessionAuthenticationMiddleware был добавлен в Django 1.7. В Django 1.7.2 его функциональность была перенесена в auth.get_user() и для обратной совместимости включена только в том случае, если 'django.contrib.auth.middleware.SessionAuthenticationMiddleware' появляется в MIDDLEWARE_CLASSES.

В Django 1.10 проверка сеанса будет включена независимо от того, включен или нет SessionAuthenticationMiddleware (в этот момент SessionAuthenticationMiddleware не будет иметь никакого значения). Вы можете добавить его в свой MIDDLEWARE_CLASSES когда-нибудь раньше, чтобы подписаться. Пожалуйста, сначала прочтите соображения по обновлению.

django.contrib.sitemaps.FlatPageSitemap¶

django.contrib.sitemaps.FlatPageSitemap переехал в django.contrib.flatpages.sitemaps.FlatPageSitemap. Старое место импорта устарело и будет удалено в Django 1.9.

Модель Поле.связанное¶

Частный атрибут django.db.models.Field.reled устарел в пользу Field.rel. Последний является экземпляром django.db.models.fields.related.ForeignObjectRel, который заменяет django.db.models.related.RelatedObject. Модуль django.db.models.related был удален, а атрибут Field.lated будет удален в Django 1.10.

Тег шаблона ssi¶

Тег шаблона ssi позволяет включать файлы в шаблон по абсолютному пути. В большинстве ситуаций развертывания это имеет ограниченное применение, и тег include часто имеет больше смысла. Этот тег устарел и будет удален в Django 1.10.

= в качестве оператора сравнения в теге шаблона if¶

Использование одного знака равенства с тегом шаблона {% if %} для проверки на равенство было недокументировано и непроверено. Теперь он устарел в пользу ==.

Синтаксис %(<foo>)s в ModelFormMixin.success_url¶

Устаревший синтаксис %(<foo>)s в ModelFormMixin.success_url устарел и будет удален в Django 1.10.

Агрегатные методы GeoQuerySet¶

Агрегатные методы collect(), extent(), extent(), make_line() и unionag() устарели и должны быть заменены их агрегатными эквивалентами на основе функций (Collect, Extent, Extent3D, MakeLine и Union).

Сигнатура метода маршрутизатора allow_migrate¶

Сигнатура метода allow_migrate() маршрутизаторов баз данных изменилась с allow_migrate(db, model) на allow_migrate(db, app_label, model_name=None, **hints).

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

После переключения на новую сигнатуру маршрутизатор также будет вызываться операциями RunPython и RunSQL.