Примечания к выпуску 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 testapplabel.TestCase.test_method_nameINSTALLED_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 UPDATENULLdjango.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для переменных , которые не присутствуют в контексте, так же как и другие конструкции шаблона.
  • SimpleLazyObjects теперь будет представлять более полезные представления в ситуациях отладки оболочки.
  • 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_texthelp_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 UserPK

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

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

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

  • Произошли изменения в способе обработки тайм-аутов в бэкэндах кеша. Явная передача 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, **kwargsget_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.

shortcutview и 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.fieldsform_classModelFormUpdateViewCreateView

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

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

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

Copyright ©2021 All rights reserved