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

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

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 запускает тесты внутри транзакции, что позволяет повысить производительность тестов (подробнее см. test performance improvements).

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

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

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

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

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

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

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

• Изучите the code as it existed before it was removed.
• Проверьте, правильно ли он работает с вашим восходящим прокси-сервером, изменив его для поддержки вашего конкретного прокси-сервера (если необходимо).
• Представьте вашу модифицированную версию 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 добавляет аргумент permanent к представлению django.views.generic.simple.redirect_to(). Это технически обратно несовместимо, если вы использовали представление redirect_to с ключом format-string под названием „permanent“, что крайне маловероятно.

Улучшения ORM¶

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

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

В слой моделей Django был добавлен ряд возможностей:

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

Несколько заметных улучшений было внесено в testing framework.

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

В тестовом клиенте была сделана пара небольших - но весьма полезных - улучшений:

• Тест Client теперь может автоматически следовать за перенаправлениями с аргументом follow в Client.get() и Client.post(). Это упрощает тестирование представлений, выдающих перенаправления.
• Теперь получить контекст шаблона в ответе, возвращенном тестовым клиентом, стало проще: вы просто получаете доступ к контексту в виде request.context[key]. Старый способ, который рассматривает request.context как список контекстов, по одному для каждого отрисованного шаблона в цепочке наследования, все еще доступен, если вам это нужно.

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

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

Обработка условных представлений¶

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

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

Django 1.1 улучшает named URL patterns с введением «пространств имен» URL.

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

Более подробную информацию можно найти в разделе the documentation on defining URL namespaces.

GeoDjango¶

В 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 protection middleware был разделен на два класса – CsrfViewMiddleware проверяет входящие запросы, а CsrfResponseMiddleware обрабатывает исходящие ответы. Объединенный класс CsrfMiddleware (который выполняет оба действия) остается для обратной совместимости, но теперь рекомендуется использовать разделенные классы, чтобы обеспечить тонкий контроль над тем, когда и где происходит обработка CSRF.
• reverse() и код, который его использует (например, тег шаблона {% url %}) теперь работает с URL-адресами в административном сайте Django, при условии, что URL-адреса администратора настроены через include(admin.site.urls) (отправка запросов администратора к представлению admin.site.root по-прежнему работает, но URL-адреса в администраторе не будут «обратимыми» при такой настройке).
• Функция include() в модулях Django URLconf теперь может принимать последовательности шаблонов URL (генерируемые patterns()) в дополнение к именам модулей.
• Экземпляры форм Django (см. the forms overview) теперь имеют два дополнительных метода, hidden_fields() и visible_fields(), которые возвращают список скрытых - т.е. <input type="hidden"> - и видимых полей формы, соответственно.
• Родовое представление redirect_to теперь принимает дополнительный аргумент в виде ключевого слова permanent. Если permanent равно True, представление будет выдавать постоянное перенаправление HTTP (код состояния 301). Если False, представление будет выдавать временное перенаправление HTTP (код состояния 302).
• Новый тип поиска в базе данных – week_day – был добавлен для DateField и DateTimeField. Этот тип поиска принимает число от 1 (воскресенье) до 7 (суббота) и возвращает объекты, значение поля которых соответствует этому дню недели. Подробности см. в разделе the full list of lookup types.
• Тег {% for %} в языке шаблонов Django теперь принимает необязательное предложение {% empty %}, которое отображается, когда {% for %} просят зациклить пустую последовательность. Примеры этого см. в the list of built-in template tags.
• Команда управления dumpdata теперь принимает в качестве аргументов имена отдельных моделей, что позволяет экспортировать данные только из определенных моделей.
• Есть новый фильтр шаблона safeseq, который работает так же, как safe для списков, помечая каждый элемент списка как безопасный.
• Cache backends теперь поддерживает команды incr() и decr() для увеличения и уменьшения значения ключа кэша. На бэкендах кэша, которые поддерживают атомарное увеличение/уменьшение - в частности, на бэкенде memcached - эти операции будут атомарными и довольно быстрыми.
• Django теперь может easily delegate authentication to the Web server через новый бэкенд аутентификации, который поддерживает стандартную переменную окружения REMOTE_USER, используемую для этой цели.
• Появилась новая функция django.shortcuts.redirect(), которая упрощает создание перенаправлений, задавая объект, имя представления или URL.
• Бэкенд postgresql_psycopg2 теперь поддерживает native PostgreSQL autocommit. Это продвинутая, специфическая для PostgreSQL функция, которая может значительно ускорить работу некоторых приложений с большими объемами чтения.