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

Заметка

Посвящается Малкольму Трединнику

17 марта 2013 года проект Django и сообщество свободного программного обеспечения потеряли очень дорогого друга и разработчика.

Малькольм был давним сотрудником Django, модельным членом сообщества, блестящим умом и другом. Его вклад в Django - и во многие другие проекты с открытым исходным кодом - почти невозможно перечислить. Многие из основной команды Django проверяли свои первые патчи; его наставничество обогатило нас. Его внимание, терпение и преданность делу всегда будут для нас источником вдохновения.

Этот выпуск Django предназначен для Малькольма.

- Разработчики Django

6 ноября 2013 г.

Добро пожаловать в Django 1.6!

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

Совместимость с Python

Django 1.6, как и Django 1.5, требует Python 2.6.5 или выше. Также официально поддерживается Python 3. Мы настоятельно рекомендуем последний минорный выпуск для каждой поддерживаемой серии Python (2.6.X, 2.7.X, 3.2.X и 3.3.X).

Django 1.6 будет последней серией выпусков с поддержкой Python 2.6; начиная с Django 1.7, минимальная поддерживаемая версия Python будет 2.7.

Python 3.4 не поддерживается, но поддержка будет добавлена ​​в Django 1.7.

Что нового в Django 1.6

Упрощенные шаблоны проектов и приложений по умолчанию

Шаблоны по умолчанию используются startproject и startapp были упрощены и модернизированы. Админы теперь включен по умолчанию в новых проектах; не сайты рамки больше не является. Теперь защита от кликджекинга включена, и в базе данных по умолчанию используется SQLite.

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

Улучшенное управление транзакциями

Управление транзакциями в Django было переработано. Автоматическая фиксация на уровне базы данных теперь включена по умолчанию. Это делает обработку транзакций более явной и должно повысить производительность. Существующие API-интерфейсы были объявлены устаревшими, и были введены новые API-интерфейсы, как описано в документации по управлению транзакциями .

Постоянные подключения к базе данных

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

Обнаружение тестов в любом тестовом модуле

Django 1.6 поставляется с новым средством запуска тестов, которое обеспечивает большую гибкость в расположении тестов. Предыдущий бегун ( django.test.simple.DjangoTestSuiteRunner ) обнаружили тесты только в models.py и tests.py модули пакета Python в INSTALLED_APPS .

Новый runner ( django.test.runner.DiscoverRunner ) использует встроенные функции обнаружения тестов unittest2 (версия unittest в стандартной библиотеке Python 2.7+ и поставляется вместе с Django). Благодаря обнаружению тестов тесты могут быть расположены в любом модуле, имя которого соответствует шаблону test*.py .

Кроме того, тестовые метки, предоставляемые для назначения конкретных тестов для запуска, теперь должны быть полными пунктирными путями Python (или путями к каталогам), а не псевдопутями. Это позволяет запускать тесты в любом месте вашей кодовой базы, а не только в . Подробнее см. Тестирование в Django ../manage.py test applabel.TestCase.test_method_name INSTALLED_APPS

Это изменение обратно несовместимо; см. примечания об обратной несовместимости .

Агрегация с учетом часовых поясов

Поддержка часовых поясов, представленная в Django 1.4, не очень хорошо работала QuerySet.dates() : агрегирование всегда выполнялось в формате UTC. Это ограничение было снято в Django 1.6. Используется QuerySet.datetimes() для выполнения агрегирования с учетом часовых поясов в DateTimeField .

Поддержка точек сохранения в SQLite

Django 1.6 добавляет поддержку точек сохранения в SQLite с некоторыми ограничениями .

BinaryField поле модели

Новое django.db.models.BinaryField поле модели позволяет хранить необработанные двоичные данные в базе данных.

Виджеты форм GeoDjango

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

check добавлена ​​команда управления для проверки совместимости

Была check добавлена ​​команда управления, позволяющая проверить, совместима ли ваша текущая конфигурация (в настоящее время ориентированная на настройки) с текущей версией Django.

Model.save() алгоритм изменен

Теперь Model.save() метод пытается напрямую обращаться к UPDATE базе данных, если экземпляр имеет значение первичного ключа. Ранее SELECT выполнялось для определения необходимости UPDATE или INSERT необходимости. Новому алгоритму нужен только один запрос для обновления существующей строки, а старому алгоритму - два. Подробнее Model.save() см.

В некоторых редких случаях база данных не сообщает, что соответствующая строка была найдена при выполнении UPDATE . Примером может служить возвращаемый триггер PostgreSQL . В таких случаях можно установить флаг для принудительного сохранения с использованием старого алгоритма.ON UPDATE NULL django.db.models.Options.select_on_save

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

  • Бэкенды аутентификации могут вызвать PermissionDenied немедленный сбой в цепочке аутентификации.
  • HttpOnly Флаг может быть установлен на CSRF печенье с CSRF_COOKIE_HTTPONLY .
  • В assertQuerysetEqual() теперь проверяет неопределенный порядок и рейзы , ValueError если не определен порядок пятнистые. Порядок считается неопределенным, если данное QuerySet не упорядочено и есть более одного упорядоченного значения для сравнения.
  • Добавлен earliest() для симметрии с latest() .
  • В дополнение к year , month и day , ОРМ теперь поддерживает hour , minute и second поиски.
  • Django теперь обертывает все PEP 249 исключения.
  • По умолчанию виджеты для EmailField , URLField , IntegerField , FloatField и DecimalField использовать новый тип атрибуты доступны в HTML5 ( type='email' , type='url' , type='number' ). Обратите внимание, что из-за беспорядочной поддержки типа number ввода с локализованными числами в текущих браузерах Django использует его только тогда, когда числовые поля не локализованы.
  • number Аргумент для ленивых множества переводов может быть предоставлен во время трансляции , а не во время определения.
  • Для пользовательских команд управления: проверка наличия допустимых параметров в командах, которые запрашивают его, с использованием BaseCommand.can_import_settings внутреннего параметра теперь выполняется независимо от обработки языкового стандарта, который должен быть активен во время выполнения команды. На последнее теперь можно влиять с помощью новой BaseCommand.leave_locale_alone внутренней опции. Дополнительные сведения см. В разделе Команды управления и языковые стандарты .
  • success_url Из DeletionMixin теперь интерполированное с его object «с __dict__ .
  • HttpResponseRedirect и HttpResponsePermanentRedirect теперь укажите url атрибут (эквивалент URL-адреса, на который будет перенаправлен ответ).
  • MemcachedCache Бэкенд кэша теперь использует последний pickle протокол доступен.
  • Добавлено SuccessMessageMixin который предоставляет success_message атрибут для FormView классов на основе.
  • Добавлены параметры django.db.models.ForeignKey.db_constraint и django.db.models.ManyToManyField.db_constraint .
  • Встроенная в админку библиотека jQuery обновлена ​​до версии 1.9.1.
  • Syndication feeds ( django.contrib.syndication ) теперь может передавать дополнительный контекст в шаблоны каналов с помощью нового Feed.get_context_data() обратного вызова.
  • Столбцы административного списка имеют column-<field_name> класс в HTML, поэтому заголовок столбца может быть стилизован с помощью CSS, например, для установки ширины столбца.
  • Уровень изоляции можно настроить в PostgreSQL.
  • blocktrans Шаблонный тег теперь учитывает TEMPLATE_STRING_IF_INVALID для переменных , которые не присутствуют в контексте, так же как и другие конструкции шаблона.
  • SimpleLazyObject s теперь будет представлять более полезные представления в ситуациях отладки оболочки.
  • Generic GeometryField теперь можно редактировать с помощью виджета OpenLayers в админке.
  • В документации есть контрольный список развертывания .
  • У diffsettings команды появилась --all возможность.
  • django.forms.fields.Field.__init__ now вызывает super() , позволяя миксинам полей реализовывать __init__() методы, которые будут надежно вызываться.
  • validate_max Параметр был добавлен BaseFormSet и formset_factory() , а также ModelForm и встроенные версии одного и того же. Уточнено поведение проверки для наборов форм с max_num . Было задокументировано ранее недокументированное поведение, защищающее наборы форм от атак с исчерпанием памяти, а недокументированный предел более 1000 max_num форм был изменен, поэтому он всегда на 1000 больше max_num .
  • Добавлено BCryptSHA256PasswordHasher для решения проблемы усечения пароля с помощью bcrypt.
  • Pillow теперь является предпочтительной библиотекой для работы с изображениями для использования с Django. PIL ожидает прекращения поддержки (поддержка будет удалена в Django 1.8). Для обновления вы должны сначала удалить PIL, а затем установить Pillow.
  • ModelForm принимает несколько новых Meta опций.
    • Поля, включенные в localized_fields список, будут локализованы (путем настройки localize в поле формы).
    • Параметры labels , help_texts и error_messages могут использоваться для настройки полей по умолчанию, подробности см. В разделе Переопределение полей по умолчанию .
  • choices Аргумент модель полей теперь принимает итератор из итерируемых вместо того , чтобы требовать итератора списков или кортежей.
  • Фразу причины можно настроить в ответах HTTP с помощью reason_phrase .
  • Давая URL следующей страницы django.contrib.auth.views.logout() , django.contrib.auth.views.password_reset() , django.contrib.auth.views.password_reset_confirm() и django.contrib.auth.views.password_change() , теперь вы можете передать имена URL , и они будут решены.
  • Новая опция определяет первичные ключи объектов для дампа. Этот вариант можно использовать только с одной моделью.dumpdata --pks
  • Добавлены QuerySet методы first() и last() которые являются удобные методы возвращающие первый или последний объект , соответствующий фильтр. Возвращает, None если совпадающих объектов нет.
  • View и RedirectView теперь поддерживают PATCH метод HTTP .
  • GenericForeignKey теперь принимает необязательный for_concrete_model аргумент, который, если установлен в, False позволяет полю ссылаться на прокси-модели. По умолчанию True сохраняется прежнее поведение.
  • LocaleMiddleware Теперь хранит активный язык в сессии , если его нет там. Это предотвращает потерю языковых настроек после сброса сеанса, например, выхода из системы.
  • SuspiciousOperation был разделен на несколько подклассов, и каждый будет регистрироваться в соответствующем именованном регистраторе в django.security иерархии регистрации. Наряду с этим изменением handler400 механизм и представление по умолчанию используются всякий раз, когда a SuspiciousOperation достигает обработчика WSGI для возврата HttpResponseBadRequest .
  • DoesNotExist Исключение теперь включает в себя сообщение , указывающее имя атрибута , используемый для поиска.
  • Для get_or_create() метода больше не требуется хотя бы один аргумент ключевого слова.
  • SimpleTestCase Класс включает в себя новый помощник утверждения для тестирования formset ошибок: assertFormsetError() .
  • Список связанных полей, добавленных к объекту QuerySet , select_related() можно очистить с помощью select_related(None) .
  • get_extra() И get_max_num() методы на InlineModelAdmin могут быть переопределены , чтобы настроить дополнительные и максимальное количество встроенных форм.
  • У наборов форм теперь есть total_error_count() метод.
  • ModelForm поля теперь могут переопределять сообщения об ошибках, определенные в полях модели, с помощью error_messages аргумента конструктора a Field . Чтобы воспользоваться преимуществами этой новой функции с настраиваемыми полями, см. Обновленные рекомендации по созданию файла ValidationError .
  • ModelAdmin теперь сохраняет фильтры в виде списка после создания, редактирования или удаления объекта. Можно восстановить предыдущее поведение очистки фильтров, установив для preserve_filters атрибута значение False .
  • Добавлен FormMixin.get_prefix (который возвращается FormMixin.prefix по умолчанию), чтобы можно было настроить prefix форму.
  • Необработанные запросы ( Manager.raw() или cursor.execute() ) теперь могут использовать стиль параметра «pyformat», где заполнители в запросе задаются как, '%(name)s' а параметры передаются как словарь, а не список (кроме SQLite). Это давно возможно (но официально не поддерживается) в MySQL и PostgreSQL, а теперь также доступно в Oracle.
  • Количество итераций по умолчанию для хэшера паролей PBKDF2 увеличено на 20%. Это обратно совместимое изменение не повлияет на существующие пароли или пользователей, которые создали подклассы, django.contrib.auth.hashers.PBKDF2PasswordHasher чтобы изменить значение по умолчанию. При необходимости пароли будут обновлены для использования нового счетчика итераций.

Обратно несовместимые изменения в 1.6

Предупреждение

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

Новая модель управления транзакциями

Изменения в поведении

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

Точки сохранения и assertNumQueries

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

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

Опция автоматической фиксации для PostgreSQL

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

Новый тестовый раннер

Для обеспечения большей согласованности с unittest модулем Python новый тестовый runner ( django.test.runner.DiscoverRunner ) не поддерживает автоматически некоторые типы тестов, которые поддерживались предыдущим runner:

  • Тесты не в models.py и tests/__init__.py файлы больше не будут найдены и бежать. Переместите их в файл, имя которого начинается с test .
  • Доктесты больше не будут обнаруживаться автоматически. Чтобы интегрировать тесты в свой набор тестов, следуйте рекомендациям в документации Python .

Django объединяет модифицированную версию doctest модуля из стандартной библиотеки Python (in django.test._doctest ) и включает некоторые дополнительные утилиты doctest. Эти утилиты устарели и будут удалены в Django 1.8; Комплекты doctest должны быть обновлены для работы с модулем doctest стандартной библиотеки (или преобразованы в unittest совместимые тесты).

Если вы хотите отложить обновления вашего набора тестов, вы можете установить для своего TEST_RUNNER параметра значение, django.test.simple.DjangoTestSuiteRunner чтобы полностью восстановить прежнее поведение теста. DjangoTestSuiteRunner устарела, но не будет удалена из Django до версии 1.8.

Удаление django.contrib.gis.tests.GeoDjangoTestSuiteRunner пользовательского средства запуска тестов GeoDjango

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

Средство выполнения django.contrib.gis.tests.GeoDjangoTestSuiteRunner тестов было удалено, а реализованная им автономная настройка выполнения тестов GeoDjango больше не поддерживается. Чтобы запустить тесты GeoDjango, просто используйте новый DiscoverRunner и укажите django.contrib.gis приложение.

Пользовательские модели пользователей в тестах

Введение нового средства запуска тестов также немного изменило способ импорта тестовых моделей. В результате любой тест, который переопределяет AUTH_USER_MODEL поведение теста с одной из тестовых пользовательских моделей Django ( django.contrib.auth.tests.custom_user.CustomUser и django.contrib.auth.tests.custom_user.ExtensionUser ), теперь должен явно импортировать пользовательскую модель в ваш тестовый модуль:

from django.contrib.auth.tests.custom_user import CustomUser

@override_settings(AUTH_USER_MODEL='auth.CustomUser')
class CustomUserFeatureTests(TestCase):
    def test_something(self):
        # Test code here ...

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

ImproperlyConfigured: AUTH_USER_MODEL refers to model 'auth.CustomUser' that has not been installed

Зависимость от часового пояса day , month и week_day поиск

В Django 1.6 появилась поддержка часовых поясов day , month и week_day поиск, когда USE_TZ есть True . Эти поиски ранее выполнялись в формате UTC независимо от текущего часового пояса.

Для этого требуются определения часовых поясов в базе данных . Если вы используете SQLite, вы должны установить pytz . Если вы используете MySQL, вы должны установить pytz и загрузить таблицы часовых поясов с помощью mysql_tzinfo_to_sql .

Добавление QuerySet.datetimes()

Когда поддержка часовых поясов, добавленная в Django 1.4, была активна, QuerySet.dates() поиск возвращал неожиданные результаты, поскольку агрегирование выполнялось в формате UTC. Чтобы это исправить, Django 1.6 вводит новый API, QuerySet.datetimes() . Для этого потребуется внести несколько изменений в ваш код.

QuerySet.dates() возвращает date объекты

QuerySet.dates() теперь возвращает список date . Раньше он возвращал список файлов datetime .

QuerySet.datetimes() возвращает список datetime .

QuerySet.dates() больше нельзя использовать на DateTimeField

QuerySet.dates() вызывает ошибку, если он используется, DateTimeField когда активна поддержка часового пояса. QuerySet.datetimes() Вместо этого используйте .

date_hierarchy требует определения часового пояса

date_hierarchy Особенность админа теперь полагается на , QuerySet.datetimes() когда он используется на DateTimeField .

Для этого требуются определения часовых поясов в базе данных, если USE_TZ есть True . Узнать больше .

date_list в общих представлениях требует определения часового пояса

По той же причине, доступ date_list в контексте дату на основе общей точки зрения требует время определения зоны в базе данных , когда мнение основано на DateTimeField и USE_TZ является True . Узнать больше .

Новые поисковые запросы могут конфликтовать с полями модели

Django 1.6 вводит hour , minute и second поиски на DateTimeField . Если бы вы модель поле называется hour , minute или second , новые поиски будут сталкиваться с вами именами поле. Добавьте явный exact поиск, если это проблема.

BooleanField больше не по умолчанию False

Если у a BooleanField нет явного default , неявным значением по умолчанию является None . В предыдущей версии Django так и было False , но это не совсем точно отражало отсутствие ценности.

Код, который полагается на значение по умолчанию, False может вызвать исключение при сохранении экземпляров новой модели в базе данных, поскольку None это недопустимое значение для BooleanField . Вы должны либо указать default=False в определении поля, либо убедиться, что для поля установлено значение True или False перед сохранением объекта.

Переводы и комментарии в шаблонах

Извлечение переводов после комментариев

Извлечение переводимых литералов из шаблонов с помощью makemessages команды теперь правильно определяет конструкции i18n, если они расположены после комментария типа {# / #} в той же строке. Например:

{# A comment #}{% trans "This literal was incorrectly ignored. Not anymore" %}

Расположение комментариев переводчика

Комментарии для переводчиков в шаблонах, указанных с помощью{# /,#} должны быть в конце строки. Если это не так, комментарии игнорируются и makemessages генерируют предупреждение. Например:

{# Translators: This is ignored #}{% trans "Translate me" %}
{{ title }}{# Translators: Extracted and associated with 'Welcome' below #}
<h1>{% trans "Welcome" %}</h1>

Цитата в reverse()

При изменении URL-адресов Django не применял django.utils.http.urlquote аргументы до их интерполяции в шаблоны URL. Эта ошибка исправлена ​​в Django 1.6. Если вы обошли эту ошибку, применив кавычки URL-адресов перед передачей аргументов reverse() , это может привести к двойным кавычкам. Если это произойдет, просто удалите цитирование URL из вашего кода. Вам также необходимо будет заменить специальные символы в URL-адресах на assertRedirects() их закодированные версии.

Хранение IP-адресов в приложении для комментариев

Приложение для комментариев теперь использует GenericIPAddressField для хранения IP-адресов комментаторов, чтобы поддерживать комментарии, отправленные с адресов IPv6. До сих пор он хранил их в файле IPAddressField , предназначенном только для поддержки IPv4. При сохранении комментария, сделанного с адреса IPv6, адрес будет автоматически усечен в базах данных MySQL и вызовет исключение в Oracle. Вам нужно будет изменить тип столбца в вашей базе данных, чтобы воспользоваться этим изменением.

Для MySQL выполните этот запрос в базе данных вашего проекта:

ALTER TABLE django_comments MODIFY ip_address VARCHAR(39);

Для Oracle выполните этот запрос:

ALTER TABLE DJANGO_COMMENTS MODIFY (ip_address VARCHAR2(39));

Если вы не примените это изменение, поведение не изменится: в MySQL адреса IPv6 без уведомления усекаются; в Oracle создается исключение. Для баз данных SQLite или PostgreSQL изменение базы данных не требуется.

Процентные литералы в cursor.execute запросах

Когда вы выполняете необработанные SQL-запросы с помощью метода cursor.execute , % было унифицировано правило удвоения процентных литералов ( ) внутри запроса. Прошлое поведение зависело от серверной части базы данных. Теперь во всех бэкэндах вам нужно только удвоить буквальные символы процента, если вы также предоставляете параметры замены. Например:

# No parameters, no percent doubling
cursor.execute("SELECT foo FROM bar WHERE baz = '30%'")

# Parameters passed, non-placeholders have to be doubled
cursor.execute("SELECT foo FROM bar WHERE baz = '30%%' and id = %s", [self.id])

SQLite пользователям необходимо проверять и обновлять такие запросы.

Текст справки полей формы модели для полей ManyToManyField

HTML-рендеринг полей формы модели, соответствующих полям ManyToManyField модели, используемым для получения жестко запрограммированного предложения:

Удерживайте «Control» или «Command» на Mac, чтобы выбрать более одного.

(или его перевод с активной локали) , налагаемого как легенда помощи , показанной вдоль них , если ни , model ни атрибуты не указаны пользователем (или эта строка была добавлена к любому , что было предусмотрено).form help_text help_text

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

Начиная с Django 1.6, в качестве специального временного обеспечения обратной совместимости, логика добавления предложения «Удерживать…» была перемещена на уровень поля формы модели и изменена для добавления текста только тогда, когда связанный виджет установлен SelectMultiple или выбран подклассы.

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

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

QuerySet итерация

QuerySet Итерация была изменена , чтобы немедленно преобразовать все выбранные строки Model объектов. В Django 1.5 и ранее выбранные строки преобразовывались в Model объекты блоками по 100 штук.

Существующий код будет работать, но количество строк, преобразованных в объекты, может измениться в определенных случаях использования. Такое использование включает частичный цикл по набору запросов или любое использование, которое завершается выполнением __bool__ или __contains__ .

Примечательно, что большинство бэкэндов базы данных извлекали все строки за один раз уже в 1.5.

По-прежнему можно Model лениво преобразовать выбранные строки в объекты с помощью этого iterator() метода.

BoundField.label_tag теперь включает форму label_suffix

Это согласуется с тем, как такие методы , как Form.as_p и Form.as_ul визуализации метки.

Если вы вручную выполняете рендеринг label_tag в своих шаблонах:

{{ form.my_field.label_tag }}: {{ form.my_field }}

вы захотите удалить двоеточие (или любой другой разделитель, который вы можете использовать), чтобы избежать его дублирования при обновлении до Django 1.6. Следующий шаблон в Django 1.6 будет отображаться идентично вышеуказанному шаблону в Django 1.5, за исключением того, что двоеточие появится внутри <label> элемента.

{{ form.my_field.label_tag }} {{ form.my_field }}

отобразит что-то вроде:

<label for="id_my_field">My Field:</label> <input id="id_my_field" type="text" name="my_field" />

Если вы хотите сохранить текущее поведение рендеринга label_tag без использования label_suffix , создайте экземпляр формы label_suffix='' . Вы также можете настроить label_suffix для каждого поля, используя новый label_suffix параметр on label_tag() .

Администратор просматривает _changelist_filters параметр GET

Чтобы добиться сохранения и восстановления фильтров представления списка, представления администратора теперь передают _changelist_filters параметр GET. Важно учитывать это изменение, если у вас есть настраиваемые шаблоны администратора или если ваши тесты основаны на предыдущих URL-адресах. Если вы хотите вернуться к исходному поведению, вы можете установить для preserve_filters атрибута значение False .

django.contrib.auth сброс пароля использует кодировку base 64 User PK

В предыдущих версиях Django использовалось кодирование User первичного ключа base 36 в представлениях сброса пароля и URL-адресах ( django.contrib.auth.views.password_reset_confirm() ). Кодирования Base 36 достаточно, если первичный ключ пользователя является целым числом, однако с введением пользовательских моделей пользователя в Django 1.5 это предположение может больше не соответствовать действительности.

django.contrib.auth.views.password_reset_confirm() был изменен, чтобы принимать uidb64 параметр вместо uidb36 . Если вы меняете это представление, например, в настраиваемом password_reset_email.html шаблоне, обязательно обновите свой код.

Для django.contrib.auth.views.password_reset_confirm() обеспечения обратной совместимости добавлена временная прокладка , позволяющая ссылкам для сброса пароля, созданным до Django 1.6, продолжать работу; это будет удалено в Django 1.7. Таким образом, пока ваш сайт работает под управлением Django 1.6 дольше, чем PASSWORD_RESET_TIMEOUT_DAYS это изменение не окажет никакого влияния. В противном случае (например, если вы обновляете напрямую с Django 1.5 до Django 1.7), то любые ссылки для сброса пароля, созданные до обновления до Django 1.7 или более поздней версии, не будут работать после обновления.

Кроме того, если у вас есть какой - либо сброс пользовательских паролей URL - адреса, вам нужно будет обновлять их, заменяя uidb36 с uidb64 и тиром , что следует , что модель с косой чертой. Также добавьте _\- в список символы, которые могут соответствовать uidb64 шаблону.

Например:

url(r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
    'django.contrib.auth.views.password_reset_confirm',
    name='password_reset_confirm'),

будет выглядеть так:

url(r'^reset/(?P<uidb64>[0-9A-Za-z_\-]+)/(?P<token>.+)/$',
    'django.contrib.auth.views.password_reset_confirm',
    name='password_reset_confirm'),

Вы также можете добавить прокладку для поддержки ссылок сброса старого стиля. Используя приведенный выше пример, вы должны изменить существующий URL, заменив его django.contrib.auth.views.password_reset_confirm на, django.contrib.auth.views.password_reset_confirm_uidb36 а также удалив name аргумент, чтобы он не конфликтовал с новым URL:

url(r'^reset/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
    'django.contrib.auth.views.password_reset_confirm_uidb36'),

Вы можете удалить этот шаблон URL-адреса после того, как ваше приложение будет развернуто с Django 1.6 для PASSWORD_RESET_TIMEOUT_DAYS .

Сериализация сеанса по умолчанию переключена на JSON

Исторически django.contrib.sessions использовался pickle для сериализации данных сеанса перед их сохранением в серверной части. Если вы используете бэкэнд сеанса подписанных файлов cookie и SECRET_KEY известен злоумышленнику (в Django нет присущей ему уязвимости, которая могла бы вызвать утечку), злоумышленник может вставить строку в свой сеанс, которая, если ее не выбрать, выполняет произвольно код на сервере. Техника для этого проста и легко доступна в Интернете. Хотя хранилище сеанса cookie подписывает данные, хранящиеся в cookie, для предотвращения взлома, SECRET_KEY утечка немедленно перерастает в уязвимость удаленного выполнения кода.

Эту атаку можно смягчить путем сериализации данных сеанса с использованием JSON, а не pickle . Чтобы облегчить это, Django 1.5.3 представил новый параметр SESSION_SERIALIZER , для настройки формата сериализации сеанса. Для обратной совместимости этот параметр по умолчанию используется pickle в Django 1.5.3, но мы изменили значение по умолчанию на JSON в 1.6. Если вы обновите и переключитесь с pickle на JSON, сеансы, созданные до обновления, будут потеряны. Хотя сериализация JSON поддерживает не все объекты Python, как это pickle делает, мы настоятельно рекомендуем использовать сериализованные сеансы JSON. При проверке кода, чтобы определить, будет ли сериализация JSON работать для вашего приложения, помните следующее:

  • JSON требует строковых ключей, поэтому вы, скорее всего, столкнетесь с проблемами, если будете использовать нестроковые ключи в request.session .
  • Установка срока действия сеанса путем передачи datetime значений в set_expiry() не будет работать, поскольку datetime значения не сериализуемы в JSON. Вместо этого вы можете использовать целые числа.

Подробнее см. Документацию по сериализации сеанса .

Изменения в Object Relational Mapper

Django 1.6 содержит много изменений в ORM. Эти изменения в основном делятся на три категории:

  1. Исправления ошибок (например, правильные предложения соединения для общих отношений, комбинирование запросов, продвижение соединения и исправления обрезки соединения)
  2. Подготовка к новым возможностям. Например, ORM теперь внутренне готов для многоколоночных внешних ключей.
  3. Генеральная уборка.

Эти изменения могут привести к некоторым проблемам совместимости. Например, некоторые запросы теперь будут генерировать разные псевдонимы таблиц. Это может повлиять QuerySet.extra() . Вдобавок некоторые запросы теперь будут давать разные результаты. Примером является exclude(condition) сложное условие (ссылка на множественные соединения внутри ). Во многих случаях затронутые запросы не давали правильных результатов в Django 1.5, но теперь это делают. К сожалению, бывают случаи, когда результаты различаются, но ни Django 1.5, ни 1.6 не дают правильных результатов.Q objects

Наконец, во внутренние API ORM внесено множество изменений.

Разное

  • Больше django.db.models.query.EmptyQuerySet нельзя создать экземпляр - его можно использовать только как класс маркера для проверки того none() , был ли вызван: isinstance(qs.none(), EmptyQuerySet)

  • Если ваш CSS / JavaScript код используется для ввода виджетов доступа HTML по типу, вы должны рассмотреть его как type='text' виджеты могут быть в настоящее время выводятся в виде type='email' , type='url' или в type='number' зависимости от соответствующих их типа поля.

  • В полях формы, error_messages которые содержат заполнитель, теперь всегда должен использоваться именованный заполнитель ( вместо ). Подробную информацию об именах заполнителей см. В соответствующей документации по полям. Изменения в 1.6 особенно коснутся и ."Value '%(value)s' is too big" "Value '%s' is too big" DecimalField ModelMultipleChoiceField

  • Некоторые error_messages для IntegerField , EmailField , IPAddressField , GenericIPAddressField , и SlugField были подавлены , потому что они дублируются сообщения об ошибках , уже предоставленные валидаторов , привязанных к полям.

  • Из-за изменения рабочего процесса проверки формы метод всегда должен возвращать значение, присутствующее в атрибуте поля. Это ограничение должно быть снова снято в Django 1.7.TypedChoiceField coerce choices

  • Произошли изменения в способе обработки тайм-аутов в бэкэндах кеша. Явная передача timeout=None больше не приводит к использованию тайм-аута по умолчанию. Теперь он установит таймаут без истечения срока действия. Передача 0 в бэкэнд кэша памяти больше не использует тайм-аут по умолчанию, и теперь значение будет установлено и истечет немедленно.

  • django.contrib.flatpages Приложение используется для установки пользовательских HTTP заголовков для отладки. Эта функция не была задокументирована, и кеширование стало неэффективным, поэтому она была удалена вместе с общей реализацией, ранее доступной в django.core.xheaders .

  • Объект XViewMiddleware был перемещен из django.middleware.doc в, django.contrib.admindocs.middleware потому что это деталь реализации admindocs, которая, как правило, не подлежит повторному использованию.

  • GenericIPAddressField теперь будет разрешать blank значения, только если null значения также разрешены. Создание GenericIPAddressField где blank разрешено, но null не разрешено , вызовет ошибку проверки модели, поскольку blank значения всегда хранятся как null . Ранее сохранение blank значения в запрещенном поле null вызывало исключение базы данных во время выполнения.

  • Если NoReverseMatch при рендеринге шаблона из метода возникает исключение, оно не заглушается. Например, приведет к сбою отрисовки шаблона при повышении . В  теге нет изменений , это приводит к сбою рендеринга шаблона, как всегда, когда он поднят.{{ obj.view_href }} view_href() NoReverseMatch {% url %} NoReverseMatch

  • django.test.Client.logout() now звонит, django.contrib.auth.logout() который отправит user_logged_out() сигнал.

  • Представления аутентификации теперь меняются местами по имени, а не по месту нахожденияdjango.contrib.auth.views . Если вы используете представления безname , вам следует обновить ваш,urlpatterns чтобы использовать django.conf.urls.url() сname параметром. Например:

    (r'^reset/done/$', 'django.contrib.auth.views.password_reset_complete')
    

    будет выглядеть так:

    url(r'^reset/done/$', 'django.contrib.auth.views.password_reset_complete', name='password_reset_complete')
    
  • RedirectView теперь имеет pattern_name атрибут, который позволяет ему выбирать цель, меняя URL-адрес.

  • В Django 1.4 и 1.5 пустая строка непреднамеренно не считалась действительным паролем. Это означало, set_password() что пустой пароль будет сохраняться как непригодный, как это set_unusable_password() делает, и, следовательно, check_password() всегда возвращаться False для пустых паролей. В этой версии это было исправлено: теперь действительны пустые пароли.

  • Администратор changelist_view ранее принимал pop параметр GET, чтобы указать, что он должен отображаться во всплывающем окне. Этот параметр был переименован, чтобы _popup соответствовать остальным представлениям администратора. Вам следует обновить свои настраиваемые шаблоны, если они используют предыдущее имя параметра.

  • validate_email() теперь принимает адреса электронной почты с localhost доменом.

  • Новая опция предотвращает удаление временного файла .pot, созданного до создания файла .po.makemessages --keep-pot

  • Недокументированное django.core.servers.basehttp.WSGIServerException удалено. Использование при socket.error условии стандартной библиотеки вместо этого. Это изменение также было выпущено в Django 1.5.5.

  • Сигнатура django.views.generic.base.RedirectView.get_redirect_url() изменилась и теперь также принимает позиционные аргументы ( ). Любая безымянная захваченная группа теперь будет передана, что может привести к тому, что, если вы не обновите подпись своего пользовательского метода.*args, **kwargs get_redirect_url() TypeError

Функции, устаревшие в версии 1.6

API управления транзакциями

В Django 1.6 управление транзакциями было полностью переработано, и текущие API устарели:

  • django.middleware.transaction.TransactionMiddleware
  • django.db.transaction.autocommit
  • django.db.transaction.commit_on_success
  • django.db.transaction.commit_manually
  • TRANSACTIONS_MANAGED установка

django.contrib.comments

Инфраструктура комментариев Django устарела и больше не поддерживается. Он будет доступен в Django 1.6 и 1.7 и удален в Django 1.8. Большинству пользователей лучше подойдет индивидуальное решение или размещенный продукт, такой как Disqus .

Код, ранее известный как django.contrib.comments , все еще доступен во внешнем репозитории .

Поддержка версий PostgreSQL старше 8.4

Срок поддержки восходящего потока для PostgreSQL 8.2 был истек в декабре 2011 года, а для 8.3 - в феврале 2013 года. Как следствие, Django 1.6 устанавливает 8.4 как минимальную официально поддерживаемую версию PostgreSQL.

Вам настоятельно рекомендуется использовать самую последнюю доступную версию PostgreSQL из-за улучшений производительности и воспользоваться преимуществами встроенной потоковой репликации, доступной в PostgreSQL 9.x.

Изменения в cycle и firstof

Система шаблонов обычно избегает всех переменных, чтобы избежать атак XSS. Однако, из - за аварии в истории, cycle и firstof теги делают свои аргументы как есть.

Django 1.6 запускает процесс исправления этого несоответствия. Библиотека future шаблонов предоставляет альтернативные реализации cycle и firstof автоматически экранирует свои входные данные. Если вы используете эти теги, вам рекомендуется включить следующую строку в верхней части ваших шаблонов, чтобы включить новое поведение:

{% load cycle from future %}

или:

{% load firstof from future %}

Теги, реализующие старое поведение, устарели, и в Django 1.8 старое поведение будет заменено новым. Чтобы обеспечить совместимость с будущими версиями Django, существующие шаблоны следует изменить для использования этих future версий.

При необходимости вы можете временно отключить автоматический экранирование с помощью mark_safe() или .{% autoescape off %}

CACHE_MIDDLEWARE_ANONYMOUS_ONLY настройка

CacheMiddleware и UpdateCacheMiddleware используется для обеспечения возможности кэширования запросов только в том случае, если они не были сделаны пользователем, вошедшим в систему. Этот механизм был в значительной степени неэффективным, потому что промежуточное программное обеспечение правильно учитывает заголовок HTTP, и этот заголовок устанавливается во многих случаях, например:Vary: Cookie

  • доступ к сеансу, или
  • с помощью CSRF-защиты, которая включена по умолчанию, или
  • с помощью клиентской библиотеки, которая устанавливает файлы cookie, например Google Analytics .

Это позволяет кешу эффективно работать для каждого сеанса независимо от CACHE_MIDDLEWARE_ANONYMOUS_ONLY настройки.

_has_changed метод для виджетов

Если вы определили свои собственные виджеты формы и определили _has_changed метод для виджета, теперь вы должны определить этот метод в самом поле формы.

module_name модель _meta attribute

Model._meta.module_name был переименован в model_name . Несмотря на то, что это частный API, он будет устаревать.

get_(add|change|delete)_permission модель _meta методы

Model._meta.get_(add|change|delete)_permission методы устарели. Даже если они не были частью общедоступного API, они также пройдут обычный путь отказа от поддержки. Вы можете заменить их , где это , или .django.contrib.auth.get_permission_codename('action', Model._meta) 'action' 'add' 'change' 'delete'

get_query_set и аналогичные методы переименованы в get_queryset

Методы, возвращающие QuerySet такой как Manager.get_query_set или ModelAdmin.queryset были переименованы в get_queryset .

Если вы пишете библиотеку, которая реализует, например, Manager.get_query_set метод, и вам необходимо поддерживать старые версии Django, вам следует переименовать метод и условно добавить псевдоним со старым именем:

class CustomManager(models.Manager):
    def get_queryset(self):
        pass # ...

    if django.VERSION < (1, 6):
        get_query_set = get_queryset

    # For Django >= 1.6, models.Manager provides a get_query_set fallback
    # that emits a warning when used.

Если вы пишете библиотеку, которая должна вызывать get_queryset метод и поддерживать старые версии Django, вам следует написать:

get_queryset = (some_manager.get_query_set
                if hasattr(some_manager, 'get_query_set')
                else some_manager.get_queryset)
return get_queryset() # etc

В общем случае настраиваемого менеджера, который реализует свой собственный get_queryset метод и вызывает этот метод и должен работать со старыми версиями Django и библиотеками, которые еще не были обновлены, полезно определить get_queryset_compat метод, как показано ниже, и использовать его внутри вашему менеджеру:

class YourCustomManager(models.Manager):
    def get_queryset(self):
        return YourCustomQuerySet() # for example

    if django.VERSION < (1, 6):
        get_query_set = get_queryset

    def active(self): # for example
        return self.get_queryset_compat().filter(active=True)

    def get_queryset_compat(self):
        get_queryset = (self.get_query_set
                        if hasattr(self, 'get_query_set')
                        else self.get_queryset)
        return get_queryset()

Это помогает свести к минимуму необходимые изменения, но также правильно работает в случае подклассов (например, RelatedManagers из Django 1.5), которые могут переопределять либо get_query_set или get_queryset .

shortcut view и URLconf

Представление shortcut было перемещено из django.views.defaults в django.contrib.contenttypes.views вскоре после выпуска 1.0, но старое расположение никогда не было устаревшим. Эта ошибка была исправлена ​​в Django 1.6, и теперь вы должны использовать новое местоположение.

URLconf django.conf.urls.shortcut также устарел. Если вы включаете его в URLconf, просто замените:

(r'^prefix/', include('django.conf.urls.shortcut')),

с участием:

(r'^prefix/(?P<content_type_id>\d+)/(?P<object_id>.*)/$', 'django.contrib.contenttypes.views.shortcut'),

ModelForm без fields или exclude

Раньше, если вы хотели ModelForm использовать все поля в модели, вы могли просто опустить Meta.fields атрибут, и все поля использовались бы.

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

По этой причине такое поведение не рекомендуется, и использование этого Meta.exclude параметра настоятельно не рекомендуется. Вместо этого все поля, предназначенные для включения в форму, должны быть явно указаны в fields атрибуте.

Если эта проблема безопасности действительно не применима в вашем случае, есть ярлык, чтобы явно указать, что должны использоваться все поля - используйте специальное значение "__all__" для атрибута fields:

class MyModelForm(ModelForm):
    class Meta:
        fields = "__all__"
        model = MyModel

Если у вас есть кастом, ModelForms который нужно использовать только в админке, есть другой вариант. У администратора есть свои собственные методы для определения полей ( fieldsets и т. Д.), Поэтому добавление списка полей в список ModelForm излишне. Вместо этого просто опустите Meta внутренний класс ModelForm или Meta.model атрибут. Поскольку ModelAdmin подкласс знает, для какой модели он предназначен, он может добавить необходимые атрибуты, чтобы получить функционирование ModelForm . Это поведение также работает для более ранних версий Django.

UpdateView и CreateView без явных полей

Общие представления CreateView и UpdateView , а также все производные от ModelFormMixin них уязвимы для проблемы безопасности, описанной в разделе выше, поскольку они могут автоматически создавать объект, ModelForm который использует все поля для модели.

По этой причине, если вы используете эти представления для редактирования моделей, вы также должны указать fields атрибут (новый в Django 1.6), который представляет собой список полей модели и работает так же, как атрибут. В качестве альтернативы вы можете установить для атрибута a, который явно определяет используемые поля. Определение подкласса или для использования с моделью, но без явного списка полей, не рекомендуется.ModelForm Meta.fields form_class ModelForm UpdateView CreateView

Изменение текста справки полей формы модели для ManyToManyField полей

Вся специальная обработка help_text атрибута ManyToManyField полей модели, выполняемая стандартными полями модели или формы модели, как описано в тексте справки полей формы модели для полей ManyToManyField выше, устарела и будет удалена в Django 1.8.

Текст справки этих полей должен обрабатываться приложениями, настраиваемыми полями форм или виджетами, как это происходит с остальными типами полей модели.

Copyright ©2020 All rights reserved