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

29 июля 2009 г.

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

Django 1.1 включает в себя ряд отличных новых функций , множество исправлений ошибок и простой способ обновления с Django 1.0.

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

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

Перед обновлением до 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 запускает тесты внутри транзакции, что позволяет повысить производительность тестов (подробности см. В разделе « Улучшения производительности тестов» ).

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

В этих случаях 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 добавляет в представление permanent аргумент django.views.generic.simple.redirect_to() . Это технически несовместимо с предыдущими версиями, если вы использовали redirect_to представление с ключом строки формата под названием «постоянный», что маловероятно.

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

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

  • Вам больше не следует использовать AdminSite.root() для регистрации эти представления администратора. То есть, если ваш URLconf содержит строку:

    (r'^admin/(.*)', admin.site.root),
    

    Вы должны изменить его на следующее:

    (r'^admin/', include(admin.site.urls)),
    

Вы должны немедленно удалить использование этой функции из своего кода.

AdminSite.root вызовет a, PendingDeprecationWarning если используется в Django 1.1. По умолчанию это предупреждение скрыто. В Django 1.2 это предупреждение будет обновлено до DeprecationWarning , которое будет громко отображаться. Django 1.3 AdminSite.root() полностью удалит .

Дополнительные сведения о нашей политике и стратегии отказа от поддержки см. В разделе «Процесс выпуска Django» .

Что нового в Django 1.1

Совсем немного: начиная с Django 1.0, мы совершили 1290 коммитов кода, исправили 1206 ошибок и добавили около 10 000 строк документации.

Основные новые функции Django 1.1:

Улучшения ORM

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

Совокупная поддержка

Теперь можно запускать SQL агрегатные запросы (например COUNT() , MAX() , MIN() и т.д.) внутри ОРМ Джанго. Вы можете выбрать, возвращать ли результаты агрегата напрямую, или же аннотировать объекты в a QuerySet с результатами агрегированного запроса.

Эта функция доступна как новые aggregate() и annotate() методы, и подробно описана в документации агрегации ОРМ .

Выражения запроса

Запросы теперь могут ссылаться на другое поле в запросе и могут проходить отношения, чтобы ссылаться на поля в связанных моделях. Это реализовано в новом F объекте; для получения полной информации, включая примеры, обратитесь к .F expressions documentation

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

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

«Неуправляемые» модели

Теперь вы можете контролировать, управляет ли Django жизненным циклом таблиц базы данных для модели, используя параметр managed модели. По умолчанию это True означает, что Django создаст соответствующие таблицы базы данных syncdb и удалит их как часть reset команды. То есть Django управляет жизненным циклом таблицы базы данных.

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

Для получения дополнительных сведений см. Документацию по этой managed опции.

Прокси-модели

Теперь вы можете создавать прокси-модели : подклассы существующих моделей, которые только добавляют поведение на уровне Python (а не на уровне базы данных) и не представлены в новой таблице. То есть новая модель является прокси для некоторой базовой модели, в которой хранятся все реальные данные.

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

Отложенные поля

В некоторых сложных ситуациях ваши модели могут содержать поля, которые могут содержать много данных (например, большие текстовые поля), или требовать дорогостоящей обработки для их преобразования в объекты Python. Если вы знаете, что эти конкретные поля вам не нужны, теперь вы можете указать Django не извлекать их из базы данных.

Вы сделаете это с помощью новых методов набора запросов defer() и only() .

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

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

Улучшения производительности тестов

Тесты, написанные с использованием среды тестирования Django, теперь выполняются значительно быстрее (во многих случаях в 10 раз быстрее).

Это было достигнуто за счет введения тестов на основе транзакций: при использовании django.test.TestCase ваши тесты теперь будут запускаться в транзакции, которая откатывается по завершении, а не путем очистки и повторного заполнения базы данных. Это приводит к огромному ускорению большинства типов модульных тестов. Обратитесь к документации TestCase и TransactionTestCase для полного описания, а также некоторые важные указания по поддержке баз данных.

Улучшения тестового клиента

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

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

Новые функции администратора

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

Редактируемые поля в списке изменений

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

«Действия» администратора

Теперь вы можете определить действия администратора, которые могут выполнять некоторые действия с группой моделей сразу. Пользователи смогут выбирать объекты на странице списка изменений, а затем применять эти массовые действия ко всем выбранным объектам.

Django поставляется с одним предопределенным действием администратора для удаления группы объектов одним махом.

Обработка условного просмотра

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

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

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

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

Для получения полной информации см. Документацию по определению пространств имен URL .

GeoDjango

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

  • Поддержка SpatiaLite - пространственной базы данных для SQLite - в качестве пространственного сервера.
  • Географические агрегаты ( Collect , Extent , MakeLine , Union ) и F выражение.
  • Новые GeoQuerySet методы: collect , geojson , и snap_to_grid .
  • Новый список методов интерфейса для GEOSGeometry объектов.

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

Прочие улучшения

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

  • Промежуточный слой защиты от CSRF был разделена на два класса - CsrfViewMiddleware проверка входящих запросы и CsrfResponseMiddleware обрабатывает исходящие ответы. Комбинированный CsrfMiddleware класс (который делает и то, и другое) остается для обратной совместимости, но теперь рекомендуется использовать классы разделения, чтобы обеспечить детальный контроль над тем, когда и где происходит обработка CSRF.
  • reverse() и код, который его использует (например, тег шаблона), теперь работает с URL-адресами на административном сайте Django при условии, что URL-адреса администратора настроены с помощью (отправка запросов администратора в представление все еще работает, но URL-адреса в админке не будут «обратимыми» »При такой настройке).{% url %} include(admin.site.urls) admin.site.root
  • include() Функция в модулях Джанго URLconf теперь могут принимать последовательности шаблонов 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 (суббота) и возвращает объекты, значение поля которых совпадает с этим днем ​​недели. См. Полный список типов поиска для подробностей.
  • Тег языка шаблонов Django теперь принимает необязательный пункт, который будет отображаться , когда просят перебрать пустую последовательность. Примеры этого см. В списке встроенных тегов шаблонов .{% for %} {% empty %} {% for %}
  • Команда dumpdata управления теперь принимает имена отдельных моделей в качестве аргументов, что позволяет экспортировать данные только из определенных моделей.
  • Есть новый safeseq шаблонный фильтр, который работает так же, как и safe для списков, отмечая каждый элемент в списке как безопасный.
  • Кэш движки теперь поддерживаютincr() и decr() команды для увеличения и уменьшения значения ключа кэша. На серверных модулях кеширования, которые поддерживают атомарное увеличение / уменьшение, особенно на модуле memcached, эти операции будут атомарными и довольно быстрыми.
  • Django теперь может легко делегировать аутентификацию веб-серверу через новый бэкэнд аутентификации, который поддерживает стандартную REMOTE_USER переменную среды, используемую для этой цели.
  • Есть новая django.shortcuts.redirect() функция, которая упрощает перенаправление с учетом объекта, имени представления или URL-адреса.
  • postgresql_psycopg2 Бэкенд теперь поддерживает родную PostgreSQL AutoCommit . Это продвинутая, специфичная для PostgreSQL функция, которая может значительно ускорить работу некоторых приложений с большим объемом чтения.

Что дальше?

Сделаем небольшой перерыв, а затем начнем работу над Django 1.2 - не отдыхать уставшим! Если вы хотите помочь, обсуждение разработки Django, включая прогресс в направлении выпуска 1.2, будет проходить ежедневно в списке рассылки django-developers и на #django-dev канале IRC на сайте irc.freenode.net . Не стесняйтесь присоединяться к обсуждениям!

Онлайн-документация Django также включает указатели о том, как внести свой вклад в Django:

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

Так оно и есть.

Copyright ©2020 All rights reserved