Примечания к выпуску 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основе X-Forwarded-Forзаголовка HTTP, обычно устанавливаемого некоторыми конфигурациями прокси.

Было продемонстрировано, что этот механизм нельзя сделать достаточно надежным для универсального использования, и что (несмотря на документацию об обратном) его включение в 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 ©2021 All rights reserved