Примечания к выпуску 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
. Было задокументировано ранее недокументированное поведение, защищающее наборы форм от атак с исчерпанием памяти, а недокументированный предел более 1000max_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
механизм и представление по умолчанию используются всякий раз, когда aSuspiciousOperation
достигает обработчика 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
аргумента конструктора aField
. Чтобы воспользоваться преимуществами этой новой функции с настраиваемыми полями, см. Обновленные рекомендации по созданию файла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. Эти изменения в основном делятся на три категории:
- Исправления ошибок (например, правильные предложения соединения для общих отношений, комбинирование запросов, продвижение соединения и исправления обрезки соединения)
- Подготовка к новым возможностям. Например, ORM теперь внутренне готов для многоколоночных внешних ключей.
- Генеральная уборка.
Эти изменения могут привести к некоторым проблемам совместимости. Например, некоторые запросы теперь будут генерировать разные псевдонимы таблиц. Это может повлиять
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
настройки.
SEND_BROKEN_LINK_EMAILS
настройка ¶
CommonMiddleware
используется для предоставления базовых отчетов о неработающих ссылках по электронной почте, если для SEND_BROKEN_LINK_EMAILS
него установлено значение
True
.
Из - за неразрешимых проблем упорядочения между
CommonMiddleware
и
LocaleMiddleware
эта функция была выделена в новое промежуточное программное :
BrokenLinkEmailsMiddleware
.
Если вы полагаетесь на эту функцию, вам следует добавить
'django.middleware.common.BrokenLinkEmailsMiddleware'
в свой
MIDDLEWARE_CLASSES
параметр и удалить SEND_BROKEN_LINK_EMAILS
из него.
_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.
Текст справки этих полей должен обрабатываться приложениями, настраиваемыми полями форм или виджетами, как это происходит с остальными типами полей модели.