Изменения в именах ограничений¶

В Django 1.1 изменен метод, используемый для генерации имен ограничений базы данных, чтобы имена были согласованными независимо от размера машинного слова. Это изменение обратно несовместимо для некоторых пользователей.

Если вы используете 32-битную платформу, вы не в курсе; в результате этого изменения вы не заметите никаких различий.

Однако пользователи 64-битных платформ могут столкнуться с некоторыми проблемами при использовании команды управления reset. До этого изменения 64-битные платформы генерировали 64-битный 16-символьный дайджест в имени ограничения; например:

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_5e8f10c132091d1e FOREIGN KEY ...

После этого изменения все платформы, независимо от размера слова, будут генерировать 32-битный 8-символьный дайджест в имени ограничения; например:

ALTER TABLE myapp_sometable ADD CONSTRAINT object_id_refs_id_32091d1e FOREIGN KEY ...

В результате этого изменения вы не сможете использовать команду управления reset для любой таблицы, созданной на 64-битной машине. Это связано с тем, что новое сгенерированное имя не будет соответствовать исторически сгенерированному имени; в результате SQL, созданный командой сброса, будет недействителен.

Если вам нужно сбросить приложение, созданное с 64-битными ограничениями, вам нужно будет вручную удалить старое ограничение перед вызовом reset.

Тестовые случаи теперь выполняются в транзакции¶

Django 1.1 запускает тесты внутри транзакции, что позволяет повысить производительность тестов (подробности см. в разделе «Улучшения производительности тестов»).

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

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

Удалено промежуточное программное обеспечение SetRemoteAddrFromForwardedFor.¶

Для удобства в Django 1.0 включен дополнительный промежуточный класс — django.middleware.http.SetRemoteAddrFromForwardedFor — который обновлял значение REMOTE_ADDR на основе HTTP-заголовка X-Forwarded-For, обычно устанавливаемого некоторыми конфигурациями прокси.

Было продемонстрировано, что этот механизм нельзя сделать достаточно надежным для общего использования, и что (несмотря на обратное в документации) его включение в Django может привести разработчиков приложений к предположению, что значение REMOTE_ADDR «безопасно» или каким-то образом надежно в качестве источника аутентификации.

Хотя это и не является прямой проблемой безопасности, мы решили удалить это промежуточное ПО в выпуске Django 1.1. Он был заменен классом, который не делает ничего, кроме выдачи предупреждения DeprecationWarning.

Если вы полагались на это промежуточное программное обеспечение, самый простой путь обновления:

• Проверьте код в том виде, в котором он существовал до удаления.

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

• Представьте свою модифицированную версию SetRemoteAddrFromForwardedFor как часть промежуточного программного обеспечения в вашем собственном проекте.

Названия загруженных файлов будут доступны позже.¶

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

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

Изменения в способе сохранения наборов форм модели.¶

В Django 1.1 BaseModelFormSet теперь вызывает ModelForm.save().

Это обратно несовместимо, если вы изменяли self.initial в __init__ набора форм модели или если вы полагались на внутренние атрибуты _total_form_count или _initial_form_count BaseFormSet. Эти атрибуты теперь являются общедоступными методами.

Исправлено экранирующее поведение фильтра join.¶

Фильтр join больше не экранирует буквальное значение, передаваемое для соединителя.

Это обратно несовместимо для особой ситуации, когда литеральная строка содержит один из пяти специальных символов HTML. Таким образом, если вы писали {{ foo|join:"&" }}, теперь вам нужно написать {{ foo|join:"&" }}.

Предыдущее поведение было ошибкой и противоречило тому, что было задокументировано и ожидаемо.

Постоянные перенаправления и общее представление redirect_to()¶

Django 1.1 добавляет аргумент «постоянный» в представление «django.views.generic.simple.redirect_to()». Это технически обратно несовместимо, если вы использовали представление redirect_to с ключом форматной строки, называемым „permanent“, что крайне маловероятно.

Улучшения ORM¶

В объектно-реляционный картограф (ORM) Django были добавлены два основных улучшения: поддержка агрегатов и выражения запросов.

Улучшения модели¶

В слой модели Django был добавлен ряд функций:

Улучшения тестирования¶

В инфраструктуру тестирования было внесено несколько заметных улучшений.

Тестирование улучшений клиента¶

В тестовый клиент было внесено несколько небольших, но очень полезных улучшений:

• Тестовый Client теперь может автоматически следовать за перенаправлениями с аргументом follow на Client.get() и Client.post(). Это упрощает тестирование представлений, которые выдают перенаправления.

• Теперь стало проще получить контекст шаблона в ответе, возвращаемом тестовым клиентом: вы просто получите доступ к контексту как request.context[key]. Старый способ, при котором request.context рассматривается как список контекстов, по одному для каждого отображаемого шаблона в цепочке наследования, по-прежнему доступен, если он вам нужен.

Новые возможности администратора¶

Django 1.1 добавляет пару отличных новых функций в интерфейс администратора Django:

Обработка условного представления¶

Django теперь имеет гораздо лучшую поддержку обработки условного представления с использованием стандартных HTTP-заголовков ETag и Last-Modified. Это означает, что теперь вы можете легко сократить обработку представлений, проверив менее затратные условия. Для многих просмотров это может привести к серьезному улучшению скорости и снижению пропускной способности.

Пространства имен URL-адресов¶

В Django 1.1 улучшены шаблоны именованных URL-адресов <naming-url-patterns>` за счет введения «пространств имен» URL-адресов.

Короче говоря, эта функция позволяет несколько раз включать одну и ту же группу URL-адресов из одного и того же приложения в URLConf Django с разными (и потенциально вложенными) именованными префиксами, которые будут использоваться при выполнении обратного разрешения. Другими словами, многократно используемые приложения, такие как интерфейс администратора Django, могут быть зарегистрированы несколько раз без конфликтов URL-адресов.

Более подробную информацию можно найти в документации по определению пространств имен URL.

ГеоДжанго¶

В Django 1.1 GeoDjango (т. е. django.contrib.gis) имеет несколько новых функций:

• Поддержка SpatiaLite — пространственной базы данных для SQLite — в качестве пространственного бэкэнда.

• Географические агрегаты (Collect, Extent, MakeLine, Union) и выражения F.

• Новые методы GeoQuerySet: Collect, geojson и snap_to_grid.

• Новый список методов интерфейса для объектов GEOSGeometry.

Более подробную информацию см. в документации GeoDjango.

Другие улучшения¶

Другие новые функции и изменения, представленные после Django 1.0, включают:

• Промежуточное ПО защиты CSRF </ref/csrf>` разделено на два класса: CsrfViewMiddleware проверяет входящие запросы, а CsrfResponseMiddleware обрабатывает исходящие ответы. Комбинированный класс CsrfMiddleware (который выполняет и то, и другое) остается для обратной совместимости, но теперь рекомендуется использовать разделенные классы, чтобы обеспечить детальный контроль над тем, когда и где происходит обработка CSRF.

• reverse() и код, который его использует (например, тег шаблона {% url %}) теперь работает с URL-адресами на административном сайте Django, при условии, что URL-адреса администратора настроены через include(admin.site.urls) (отправка запросов администратора в представление admin.site.root по-прежнему работает, но URL-адреса в администраторе не будут «обратимыми» при такой настройке).

• Функция include() в модулях URLconf Django теперь может принимать последовательности шаблонов URL (сгенерированные patterns()) в дополнение к именам модулей.

• Экземпляры форм Django (см. обзор форм) теперь имеют два дополнительных метода: hidden_fields() и visible_fields(), которые возвращают список скрытых, т. е. <input type="hidden">, и видимых полей формы соответственно.

• Общее представление redirect_to теперь принимает дополнительный аргумент ключевого слова permanent. Если параметр «permanent» имеет значение «True», представление будет генерировать постоянное перенаправление HTTP (код состояния 301). Если установлено значение «False», представление выполнит временное перенаправление HTTP (код состояния 302).

• Новый тип поиска в базе данных — «week_day» — был добавлен для DateField и DateTimeField. Этот тип поиска принимает число от 1 (воскресенье) до 7 (суббота) и возвращает объекты, в которых значение поля соответствует этому дню недели. Подробности смотрите в полном списке типов поиска <field-lookups>.

• Тег {% for %} в языке шаблонов Django теперь принимает необязательное предложение {% пустой %}, которое будет отображаться, когда {% for %} запрашивается для перебора пустой последовательности. Примеры этого см. в списке встроенных тегов шаблонов.

• Команда управления dumpdata теперь принимает имена отдельных моделей в качестве аргументов, что позволяет экспортировать данные только из определенных моделей.

• Появился новый шаблонный фильтр safeseq, который работает так же, как safe для списков, помечая каждый элемент в списке как безопасный.

• Бэкэнды кэширования теперь поддерживают команды incr() и decr() для увеличения и уменьшения значения ключа кэша. На серверах кэширования, поддерживающих атомарное увеличение/уменьшение (в первую очередь на memcached), эти операции будут атомарными и довольно быстрыми.

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

• Появилась новая функция django.shortcuts.redirect, которая упрощает выполнение перенаправлений по объекту, имени представления или URL-адресу.

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