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

В статье "Django 1.2 release notes" автор говорит об основных изменениях, которые вошли в данную версию.

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

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

Краткий обзор

В Django 1.2 вводится ряд важных новых функций, среди которых:

TЭто лишь основные моменты более подробный список изменений можно посмотреть ниже.

См. также

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

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

Однако, часть функций изменилась таким образом, что для некоторых пользователей, будут несовместимы. Существенные изменения:

  • Удалена поддержка Python 2.3. Смотри подробнее ниже.

  • Новый фреймворк защиты от CSRF не является обратно-совместимым со старой системой. Пользователи старой системы смогут продолжить работу до выхода Django 1.4.

    Однако, обновление до новой системы защиты от CSRF требует нескольких важных обратно-несовместимых изменений. Подробности о CSRF-защите, ниже.

  • Авторы пользовательских Field-подклассов должны знать, что многие методы претерпели изменения в прототипе, подробнее об этом ниже.

  • Внутренняя организация тэгов шаблона немного изменилась; авторы пользовательских тэгов шаблона, которые должны сохранять состояние (например пользовательские тэги управления потоком ), обязаны гарантировать, что их код соответствует новым правилам для stateful тэгов шаблона.

  • Декораторы user_passes_test(), login_required(), и permission_required(), из django.contrib.auth применяются только к функциям и больше не работают с методами. Есть простое одноразовое исправление, подробности ниже.

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

Совместимость с Python

Хотя это и не новая функция, но важно отметить, что Django 1.2 представляет первую смену в нашей политике совместимости с того момента, когда Python был впервые опубликован. Предыдущие выпуски Django были проверены и поддерживались версиями Python 2.x - 2.3; Хотя, Django 1.2 официально поддерживает Python 2.3. Таким образом, теперь минимальная версия Python, требуемая для Django -  2.4, и Django тестируется и поддерживается Python 2.4, 2.5, 2.6, и будет поддерживаться еще не выпущенным Python 2.7.

Эти изменения коснутся лишь небольшого количества пользователей Django, поскольку сегодня большинство продавцов операционных систем предоставляют по умолчанию Python 2.4 или более новые версии. И если Вы всё ещё     используете Python 2.3, то вам придется пользоваться Django 1.1, пока не обновитесь до более поздней версии Python; в наши планы входит поддерживать безопасность Django 1.1 до выхода Django 1.3.

План поддержки Python 2.x для Django, и возможный переход на Python 3.x, в настоящее время находится в разработке, и будет объявлен до выхода Django 1.3.

Что нового в Django 1.2

Поддержка множества баз данных

Django 1.2 добавляет возможность использовать больше, чем одну базу данных в вашем проекте Django. Запросы могут быть направлены на определенную базу данных, используя метод вызова  using() при выполнении запроса; индивидуальные объекты могут быть сохранены в указанную базу данных, с помощью передачи аргумента using в момент сохранения экземпляра.

Валидация данных в модели

Образцы модели теперь имеют поддержку валидации их собственных данных, теперь как поля модели, так и поля формы принимают настраиваемый список валидаторов Обратите внимание, однако, что валидация должна все ещё выполняться эксплицитно. Простой вызов метода образца модели save() не будет выполнять никакой валидации данных образца.

Улучшенная поддержка CSRF

Django сейчас имеет значительно улучшенную защиту от Кроссайтовых атак (CSRF). Этот тип атак происходит, когда вредоносный веб-сайт содержит ссылки, кнопку или javascript, который предназначен для выполнения некоторых действий на Вашем веб-сайте, используя учетные данные вошедшего в систему пользователя, который посещает вредоносный сайт. Также производится защита от похожего типа атак, ' login CSRF ', где атакующий  сайт обманывает браузер пользователя, регистрируясь на сайте под чужим именем.

Фреймворк Сообщений

Django теперь включает в себя надежный и настраиваемый фреймворк сообщений, со встроенной поддержкой обмена сообщениями на основе cookie и session, как для анонимных, так и для аутентифицированных клиентов. Фреймворк сообщений заменяет устаревший API пользовательских сообщений и позволяет Вам временно сохранить сообщения в одном запросе и восстановить их для отображения в последующем запросе.

Разрешения объектного уровня

Была добавлена база для определения разрешений на объектном уровне. Несмотря на отсутствие реализации этого в ядре, бэкэнд пользовательской аутентификации может это выполнять, и делает он это через django.contrib.auth.models.User. Дополнительную информацию смотри здесь: authentication docs.

Разрешения для анонимных пользователей

Если Вы задали бэкэнду пользовательской аутентификации supports_anonymous_user значение True, то AnonymousUser будет проверять бэкенд на наличие разрешений, также как это делал User. Это полезно для централизованной обработки разрешений - приложения всегда могут направить запрос  на бэкэнд идентификации, разрешено ли это или нет. Дополнительную информацию смотри здесь: authentication docs.

Ослабленные требования для имен пользователя

Поле встроенного имени пользователя пользовательской модели теперь позволяет более широкий диапазон символов, включая такие символы, как: "@", "+", "." и "-".

E-mail-бэкенды

Вы теперь можете настроить Django таким образом, чтобы он отправлял почту. Теперь, для отправки почты, вместо использования SMTP, Вы можете  выбрать конфигурируемый e-mail-бэкэнд. Если ваш хостинг-провайдер использует "песочницу", или какой-либо другой не-SMTP метод отправки почты, Вы можете теперь сконфигурировать e-mail бэкэнд, который позволит стандартным методам отправки писем Django использовать эти возможности.

Это также облегчает отладку отправки почты - Django поставляется с бэкэндом, что позволяет вам отправлять почту в файл, консоль, память или просто «выбрасывать».

'Умный' тег if

Чтобы тег if был более мощным, он был обновлён. Сначала была добавлена поддержка операторов сравнения.  Вам больше не придется вводить:

{% ifnotequal a b %}
 ...
{% endifnotequal %}

...поскольку Вы теперь можете сделать следующее:

{% if a != b %}
 ...
{% endif %}

Поддерживаются операторы ==, !=, <, >, <=, >= и in, все из которых работают как операторы Python, в дополнение к операторам and, or и not которые уже поддерживались.

Кроме того, теперь можно использовать фильтры в выражении if. Например:

<div
  {% if user.email|lower == message.recipient|lower %}
    class="highlight"
  {% endif %}
>{{ message }}</div>

Кэширование шаблона

В предыдущих версиях Django, каждый раз, когда Вы отдавали шаблон, он снова перезагружался с диска. В Django 1.2, Вы можете использовать загрузчик кешированных шаблонов, чтобы загрузить шаблоны один раз, а затем использовать закешированный результат для каждого последующего рендеринга. Это может привести к значительному повышению производительности, если ваши шаблоны разбиты на множество мелких подшаблонов (с помощью тегов {% extends %} или {% include %}).

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

Натуральные ключи в fixtures

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

Приостановка тестов после первой неудачи

Тестовая подкоманда django-admin.py, и скрипт runtests.py  используемый для запуска собственного набора тестов Django, поддерживает новую опцию --failfast. Эта опция заставляет запускатель тестов завершать тесты после первого случая неудачного теста, вместо того, чтобы продолжать другие тесты. Кроме того, команда Ctrl-C во время выполнения теста была усовершенствована, чтобы постепенно приостановить процесс тестирования, и не терять данные тех тестов, которые получили какие-либо результаты, а не резко обрывать процесс с потерей данных, как это было раньше.

BigIntegerField

Модели могут теперь использовать 64 битный тип BigIntegerField.

Улучшенная локализация

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

Readonly_fields в ModelAdmin

django.contrib.admin.ModelAdmin.readonly_fields добавлен, чтобы сделать доступными не-редактируемые поля на страницах добавления/изменения для моделей и инлайнов. Поле и вычисляемые значения могут отображаться рядом с редактируемыми полями.

Настраиваемая подсветка синтаксиса

Вы теперь можете использовать переменную окружения DJANGO_COLORS для изменения или исключения цвета, используемого django-admin.py, чтобы предоставить django-admin.py чтобы предоставить подсветку синтаксиса.

 

Syndication feeds в качестве views

Syndication feeds могут теперь использоваться непосредственно как views в вашем URLconf. Это означает, что Вы можете поддерживать полный контроль над URL-структурой  ваших фидов. Как любой view, feeds views пропускают требуемый объект, поэтому Вы можете делать все, что обычно делали с помощью view, подобно пользовательскому контролю доступа, или сделав фид названным URL.

GeoDjango

Наиболее значимая функция в GeoDjango для версии 1.2 - поддержка множественных пространственных баз данных. В результате, следующие spatial database backends теперь включают:

  • django.contrib.gis.db.backends.postgis
  • django.contrib.gis.db.backends.mysql
  • django.contrib.gis.db.backends.oracle
  • django.contrib.gis.db.backends.spatialite

GeoDjango теперь поддерживает большие возможности, добавленные в релиз PostGIS 1.5. Новые функции включают поддержку для geography type и создание distance queries с помощью неодноточечных конфигураций на географических системах координат.

Была добавлена поддержка 3D-полей, которая может быть активирована путем установки dim на значение 3 в GeometryField. Extent3D  и метод extent3d() GeoQuerySet были добавлены, как часть этой функции.

В версию Django 1.2 были добавлены следующие GeoQuerySet-методы:

Был обновлён GEOS interface для того, чтобы использовать библиотеку потокобезопасных функций написанных на C, если поддерживается операционной системой.

GDAL interface позволяет теперь пользователю отфильтровать результат с помощью spatial_filter, полученный после итераций по Layer.

И наконец, документация GeoDjango's documentation теперь включена в Django, а не размещается отдельно в geodjango.org.

Обработка с помощью JavaScrip встроенных связанных объектов в админке

Новые символы в тэге шаблона now: c и u

TАргумент к now получил два новых символа: c, чтобы обозначить, что значение datetime должно быть отформатировано в формате ISO 8601, и u, который позволяет выводить микросекундную часть значений времени или datetime.

Они также доступны в таких шаблонных фильтрах, как date и time в библиотеке шаблонного тэга humanize и в новом фреймворке format localization.

Изменения без обратной совместимости в релизе Django 1.2

Вышеупомянутые новые функции были внедрены везде, где это возможно в обратно-совместимой манере через нашу политику API-стабильности. Это означает, что фактически весь существующий код, который работал под Django 1.1, продолжит работать и под Django 1.2; хотя, такой код начнет выдавать предупреждения (подробности смотри ниже).

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

CSRF-защита

Были сделаны большие изменения в работе защиты от CSRF (Cross-site request forgery), детально изложенные в документации CSRF. Вот основные изменения, о которых должны знать разработчики:

  • CsrfResponseMiddleware и CsrfMiddleware устарели и будут полностью удалены в Django 1.4, в пользу тега, который должен быть вставлен в форму.
  • Все contrib-приложения используют csrf_protect decorator для защиты view. Это требует использования тега csrf_token в шаблоне, поэтому, если Вы использовали настраиваемые шаблоны для contrib views, Вы ДОЛЖНЫ ПРОЧЕСТЬ ИНСТРУКЦИИ чтобы исправить эти шаблоны.
  • CsrfViewMiddleware входит в MIDDLEWARE_CLASSES по умолчанию. Поэтому CSRF защита включается по умолчанию, так, что views, которые принимают POST-запросы, должны быть написаны для работы с middleware. Инструкции о том, как это сделать, можно посмотреть в документации CSRF.
  • CSRF-код, связанный с CSRF, перемещён из пакета contrib в core (с обратной совместимостью импорта в старом местоположении, которые являются устаревшими и прекратят поддерживаться в Django 1.4).
Field get_db_prep_*()

До версии 1.2 настраиваемое поле имело опцию определения нескольких функций для поддержки преобразования значений Python в значения, совместимые с базой данных. Пользовательское (custom) поле могло бы выглядеть примерно так:

class CustomModelField(models.Field):
    # ...

    def get_db_prep_save(self, value):
        # ...

    def get_db_prep_value(self, value):
        # ...

    def get_db_prep_lookup(self, lookup_type, value):
        # ...

В версии 1.2, эти три метода претерпели изменения в прототипе, и было внедрено два дополнительных метода:

class CustomModelField(models.Field):
    # ...

    def get_prep_value(self, value):
        # ...

    def get_prep_lookup(self, lookup_type, value):
        # ...

    def get_db_prep_save(self, value, connection):
        # ...

    def get_db_prep_value(self, value, connection, prepared=False):
        # ...

    def get_db_prep_lookup(self, lookup_type, value, connection, prepared=False):
        # ...

Эти изменения необходимы для поддержки нескольких баз данных: get_db_prep_* больше не может делать каких-либо предположений относительно базы данных, для которой оно готовится. Аргумент connection теперь предоставляет методы подготовки с конкретным коннектом, для которого готовится значение.

Существует два новых метода для разделения требований к общей обработки данных, и данные требования зависят от конкретной базы данных. Аргумент prepared используется для  указания метода подготовки базы данных, чтобы выяснить, была ли выполнена общая подготовка значения. Если неподготовленное (т.е. prepared=False) значение передаётся в get_db_prep_*(), то они должны вызвать соответствующие запросы get_prep_*() для общей подготовки данных.

Были предоставлены функции преобразования, которые прозрачно преобразуют функции старого типа в новые. Однако, эта функция преобразования будет удалена из Django 1.4, поэтому вам следует обновить определения полей (Field definitions), чтобы использовать новый тип функции.

Если ваши методы get_db_prep_*() не использовали соединение с базой данных, то вы сможете обновиться, переименовав get_db_prep_value() на get_prep_value() и get_db_prep_lookup() на get_prep_lookup()`.Если вам для этого нужна специальная база данных, то вам необходимо будет реализовать функцию выполнения ``get_db_prep_* которая использует аргумент connection, чтобы разрешить значения, специальные для базы данных.

Теги шаблонов, хранящие состояние (Stateful template tags)

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

Все встроенные в Django теги безопасны для использования с загрузчиком кешированных шаблонов, но если вы используете настраиваемые теги в шаблонах, которые приходят из пакетов сторонних разработчиков, или написаны вами, то вы должны убедиться, что реализация узла (Node) для каждого тега является потоко-безопасным.  Для получения дополнительной информации см. template tag thread safety considerations.

Вам также может быть необходимо обновить ваши шаблоны, если Вы полагались на выполнение тэгов шаблона Django, не являющихся потокобезопасными. Тэг cycle скорее всего, будет затронут в этом случае, особенно если использован в сочетании с тегом include. Рассмотрим следующий фрагмент шаблона:

{% for object in object_list %}
    {% include "subtemplate.html" %}
{% endfor %}

с шаблоном subtemplate.html который имеет следующий вид:

{% cycle 'even' 'odd' %}

Используя "потоко-небезопасный", pre-Django 1.2 рендерер, это вывело бы следующий результат:

even odd even odd ...

Используя потокобезопасный Django 1.2 рендерер, Вы вместо этого получите следующее:

even even even even ...

Это происходит из-за того, что каждый рендеринг тега include является независимым рендерингом. Когда тэг cycle был потокобезопасным, состояние тэга cycle пропадало между многочисленными исполнениями одного и того же тега include. А, когда тэг cycle является потокобезопасным, это пропадание не происходит.

user_passes_test, login_required и permission_required

django.contrib.auth.decorators предоставляет декораторы login_required, permission_required и user_passes_test. Раньше было возможно использовать этих декораторы как в функциях (где первым аргументом является 'request') так и в методах (где первым аргументом является 'self', а вторым - 'request'). К сожалению, были обнаружены недостатки в коде поддержки: он  работает только в ограниченном числе случаев, и выдает ошибки, которые очень сложно исправить, когда он не работает.

По этой причине была удалена 'авто подстройка', и если Вы используете эти декораторы в методах, то вам надо будет применить вручную django.utils.decorators.method_decorator(), чтобы преобразовать декоратор в тот, который работает с методами. Например, если бы Вы изменили следующий код:

class MyClass(object):

    @login_required
    def my_view(self, request):
        pass

на:

from django.utils.decorators import method_decorator

class MyClass(object):

    @method_decorator(login_required)
    def my_view(self, request):
        pass

или:

from django.utils.decorators import method_decorator

login_required_m = method_decorator(login_required)

class MyClass(object):

    @login_required_m
    def my_view(self, request):
        pass

Для тех из Вас, кто следует за всеми изменениями, можно сказать, что это изменение также применяется к другим декораторам, представленным с версии 1.1, включая csrf_protect, cache_control и что-нибудь созданное с использованием decorator_from_middleware.

Изменение поведения тега if

Благодаря новым функциям в теге if такие имена переменных, как ‘and’, ‘or’ и ‘not’ больше не используются. Ранее это работало в некоторых случаях, даже при том, что эти строки обычно рассматривались, как ключевые слова. Теперь, статус ключевого слова всегда является предписанным, и такой код, как {% if not %} или{% if and %} будет порождать исключение TemplateSyntaxError.

 

Код статуса завершения Запускателя тестов (Test runner)

Код статуса завершения запускателя тестов (tests/runtests.py и python manage.py test) не будет выводить число ошибок тестирования, после того, как их количество превысит 256. Теперь, для успешного тестирования, код статуса завершения для запускателя тестов должен быть равен 0 (не должно быть ни одной ошибки тестирования) или 1 для любого количества ошибок тестирования. При необходимости, количество ошибок можно найти после завершения тестирования в отчёте запускателя тестов.

Cookie-кодирование

ModelForm.is_valid() и  ModelForm.errors

Большая часть работы по валидации для ModelForms была перемещена на модельный уровень. В результате, когда Вы впервые вызываете ModelForm.is_valid(), доступ к ModelForm.errors или иным способом вызываете форму валидации, то ваша модель будет очищена на месте. Такое преобразование происходило раньше при сохранении модели. Если вам нужен немодифицированный образец вашей модели, то вам следует передать копию ModelForm-конструктору.

BooleanField на MySQL

В предыдущих версиях Django, модели BooleanField под MySQL вернуло бы его значение как 1 или 0, а не True или False; для большинства людей это не было проблемой, потому что bool является подклассом int в Python. Однако в Django 1.2, BooleanField на MySQL корректно возвращает реальный bool. Единственный раз, когда это должно вызывать вопрос, это тогда, когда Вы ожидали бы, что метод repr класса BooleanField напечатает 1 или 0.

Изменения в интерпретации max_num в FormSets

В рамках усовершенствований, внесенных в обработку FormSets, значение по умолчанию и интерпретация параметра max_num для django.forms.formsets.formset_factory() и функции django.forms.models.modelformset_factory() изменилось незначительно. Это изменение также влияет на то, как параметр max_num используется для встроенных объектов админки.

Раньше, значение по умолчанию для max_num было равно 0. И FormSets использовал boolean-значение max_num чтобы определить надо ли наложить ограничение на количество сгенерированных форм. Значение по умолчанию 0 подразумевало, что по умолчанию нет никаких ограничений количества форм в FormSet.

Начиная с версии 1.2, значение по умолчанию для max_num было изменено на None, и FormSets теперь будет отличать значение None и значение 0. Значение None указывает, что не было наложено никаких ограничений на количество форм; значение 0 iуказывает, что должно быть введено максимум 0 форм. Это не обязательно должно означать, что никакие формы не будут отображены. Для более подробной информации смотри документацию  ModelFormSet.

Если Вы вручную задали значение 0 для max_num, Вы будете вынуждены обновить ваш FormSet и/или определения админки.

Устаревшие возможности в версии 1.2

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

Если в  Django 1.2 код будет использовать функции, указанные ниже, то появится предупреждение PendingDeprecationWarning. По умолчанию это предупреждение не будет появляться, но может активизироваться при использовании модуля предупреждений, или при запуске Python с помощью флажка -Wd or -Wall.

В Django 1.3, эти предупреждения станут DeprecationWarning, и будут появляться. А в Django 1.4 поддержка этих функций будет полностью удалена.

См. также

Более подробную информация можно посмотреть здесь: Django's release process и здесь: deprecation timeline.

Указание баз данных

До версии 1.1, Django использовал ряд параметров для контроля доступа к одной базе данных. В Django 1.2 вводится поддержка нескольких баз данных, и, как результат, изменился способ определения параметров баз данных.

Любой существующий файл настроек Django продолжит работать до выхода Django 1.4. Все старые настройки базы данных будут автоматически преобразованы в новый формат.

В старом формате (до версии 1.2), был ряд переменных, начинающихся с DATABASE_. Например:

DATABASE_NAME = 'test_db'
DATABASE_ENGINE = 'postgresql_psycopg2'
DATABASE_USER = 'myusername'
DATABASE_PASSWORD = 's3krit'

Эти настройки содержатся теперь в словаре под именем DATABASES. Каждый элемент в словаре соответствует одному подключению к базе данных, при чём под именем 'default' хранятся настройки соединения с базой данных по умолчанию. Названия настроек также были сокращены, чтобы отразить тот факт, что они хранятся в словаре. Примерные настройки могли бы выглядеть следующим образом:

DATABASES = {
    'default': {
        'NAME': 'test_db',
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'USER': 'myusername',
        'PASSWORD': 's3krit',
    }
}

Это относится к следующие настройкам:

Старые настройки Новые настройки
DATABASE_ENGINE ENGINE
DATABASE_HOST HOST
DATABASE_NAME NAME
DATABASE_OPTIONS OPTIONS
DATABASE_PASSWORD PASSWORD
DATABASE_PORT PORT
DATABASE_USER USER
TEST_DATABASE_CHARSET TEST_CHARSET
TEST_DATABASE_COLLATION TEST_COLLATION
TEST_DATABASE_NAME TEST_NAME

 

Эти изменения также необходимы, если вы вручную создаёте соединение с базой данных, используя DatabaseWrapper() из вашей базы данных бэкэнда.

В дополнение к изменениям в структуре, Django 1.2 удаляет специальную обработку встроенных бэкендов базы данных. Все бэкэнды базы данных  должны теперь указываться с помощью полного имени модуля (django.db.backends.postgresql_psycopg2, а не просто postgresql_psycopg2).

Бэкэнд базы данных postgresql

Библиотека psycopg1 не обновлялась с октября 2005. В результате, бэкэнд базы данных postgresql, который использует эту библиотеку, был удалён.

Если Вы в настоящее время используете бэкэнд postgresql Вам следует перейти к использованию бекенда postgresql_psycopg2. Чтобы обновить свой код, установите библиотеку psycopg2 и измените настройки DATABASE_ENGINE, чтобы использовать django.db.backends.postgresql_psycopg2.

Middleware перезаписи CSRF в ответе

CsrfResponseMiddleware, которое автоматически вставляло лексемы CSRF в POST-формы исходящих страниц, было упразднено в пользу метода тега (смотри выше), и будет полностью удалено в Django 1.4 CsrfMiddleware, которая включала в себя функциональность CsrfResponseMiddleware и CsrfViewMiddleware также была упразднена.

Кроме того, модуль CSRF был перемещён из пакета contrib в пакет core, а команда импорта должна быть изменена, как описано в примечаниях к обновлениям.

SMTP-соединение

Класс SMTPConnection был заменён на общее E-mail API бэкэнда. Вот пример старого кода, который явно иллюстрирует SMTP-соединение:

from django.core.mail import SMTPConnection
connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)

должен теперь вызывать get_connection() для создания экземпляра generic e-mail connection:

from django.core.mail import get_connection
connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)

В зависимости от значения переменной EMAIL_BACKEND он может и не вернуть SMTP-соединение. Если Вы явно хотите указать SMTP-соединение для отправки почты, то вы можете явно запросить SMTP connection:

from django.core.mail import get_connection
connection = get_connection('django.core.mail.backends.smtp.EmailBackend')
messages = get_notification_email()
connection.send_messages(messages)

Если ваш запрос на создание экземпляра SMTPConnection затребовал дополнительные аргументы, то они могут быть переданы в метод get_connection():

connection = get_connection('django.core.mail.backends.smtp.EmailBackend', hostname='localhost', port=1234)

API пользовательских сообщений

API для хранения сообщений в модели Message (через user.message_set.create) теперь упразднён и будет удален из Django 1.4 согласно стандартным правилам.

Чтобы обновить код, вам необходимо заменить следующее:

user.message_set.create('a message')

на:

from django.contrib import messages
messages.add_message(request, messages.INFO, 'a message')

Кроме того, если использовать метод, то необходимо заменить следующее:

for message in user.get_and_delete_messages():
    ...

на:

from django.contrib import messages
for message in messages.get_messages(request):
    ...

Для получения дополнительной информации см. полную документацию. Вам следует обновить свой код для немедленного использования нового API.

Вспомогательные функции форматирования даты

django.utils.translation.get_date_formats() и django.utils.translation.get_partial_date_formats() были заменены на django.utils.formats.get_format(), который знает о локали в случае, когда флаг USE_L10N имеет значение True, и возвращает настройки по умолчанию, если имеет значение False.

Чтобы получить другие форматы даты, вместо:

from django.utils.translation import get_date_formats
date_format, datetime_format, time_format = get_date_formats()

используйте:

from django.utils import formats

date_format = formats.get_format('DATE_FORMAT')
datetime_format = formats.get_format('DATETIME_FORMAT')
time_format = formats.get_format('TIME_FORMAT')

или, при непосредственном форматировании значения даты:

from django.utils import formats
value_formatted = formats.date_format(value, 'DATETIME_FORMAT')

То же самое относится и к globals в django.forms.fields:

  • DEFAULT_DATE_INPUT_FORMATS
  • DEFAULT_TIME_INPUT_FORMATS
  • DEFAULT_DATETIME_INPUT_FORMATS

Используйте django.utils.formats.get_format() для получения соответствующих форматов.

 

email_re

Недокументированное регулярное выражение для валидации адреса электронной почты было перемещено из django.form.fields в django.core.validators. Если Вы им пользуетесь, то вам придется обновить свой imports.

Запускатели тестов (test runners), базирующиеся на функции

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

Feed в django.contrib.syndication.feeds

django.contrib.syndication.feeds.Feed был заменён на django.contrib.syndication.views.Feed. Старые feeds.Feed были исключены, и будут совсем удалены в Django 1.4.

Новый класс имеет почти идентичный API, но позволяет образцам использоваться в качестве views. Например, рассмотрим использование старого фреймворка в следующем URLconf:

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

feeds = {
    'latest': LatestEntries,
    'categories': LatestEntriesByCategory,
}

urlpatterns = patterns('',
    # ...
    (r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed',
        {'feed_dict': feeds}),
    # ...
)

Используя новый Feed class, эти feeds могут быть развернуты непосредственно как views:

from django.conf.urls.defaults import *
from myproject.feeds import LatestEntries, LatestEntriesByCategory

urlpatterns = patterns('',
    # ...
    (r'^feeds/latest/$', LatestEntries()),
    (r'^feeds/categories/(?P<category_id>\d+)/$', LatestEntriesByCategory()),
    # ...
)

Если Вы в настоящее время используете feed() view, то нет необходимости изменять LatestEntries, не считая подклассификации Feed class. Исключением является случай, когда Django автоматически определяет имя шаблона, чтобы использовать для формирования описания feed и названия элементов (если Вы не указали title_template и атрибуты description_template). Вам следует всегда указывать title_template и атрибуты description_template или предоставить методы item_title() и item_description()

Однако, LatestEntriesByCategory использует метод get_object() с аргументом bits для указания конкретной категории. В новом Feed class, метод get_object() принимает запрос и аргументы от URL, и выглядит примерно так:

from django.contrib.syndication.views import Feed

from django.shortcuts import get_object_or_404
from myproject.models import Category

class LatestEntriesByCategory(Feed):
    def get_object(self, request, category_id):
        return get_object_or_404(Category, id=category_id)

    # ...

Кроме того, метод get_feed() на Feed теперь принимает различные аргументы, которые могут воздействовать на Вас, если Вы напрямую используете Feed classes. Вместо того, чтобы просто принимать дополнительный аргумент url он теперь принимает 2 аргумента: объект, возвращенный его собственным методом get_object(), и текущий объект request.

Чтобы учесть Feed classes не инициализируемые для каждого запроса, метод __init__() теперь не принимает никаких аргументов по умолчанию. Ранее он принял бы slug от URL и объекта request.

В соответствии с передовой практикой RSS, RSS feeds будут теперь включать элемент atom:link. Вам может потребоваться обновить свои тесты, чтобы принять это во внимание.

Более подробную информацию смотри здесь: syndication framework documentation.

Tехнические идентификаторы сообщения

Вплоть до версии Django 1.1 использовались технические идентификаторы сообщений чтобы предоставить локализаторам возможность переводить форматы даты и времени (например, DATETIME_FORMAT, DATE_FORMAT, TIME_FORMAT). Они были заменены новой инфраструктурой Format localization которая дает возможность локализаторам задавать эту информацию в файле formats.py в соответствующем каталоге django/conf/locale/<locale name>/.

GeoDjango

Чтобы разрешить поддержку нескольких баз данных, была существенно изменена внутренняя организация баз данных GeoDjango. Самое большое обратно-несовместимое изменение состоит в том, что модуль django.contrib.gis.db.backend был переименован на django.contrib.gis.db.backends, где теперь находятся spatial database backends. Последующие разделы предоставляют информацию о наиболее  популярных API, которые затрагивали эти изменения.

Пространственный бэкэнд

До создания отдельных пространственных бэкэндов, объект django.contrib.gis.db.backend.SpatialBackend был представлен как абстракция для проведения самоанализа на предмет возможностей пространственных баз данных. Все атрибуты и подпрограммы, предоставленные SpatialBackend теперь являются частью атрибута ops бэкэнда базы данных.

Старый модуль django.contrib.gis.db.backend по-прежнему используется для предоставления обратно-совместимого доступа к объекту SpatialBackend который является лишь псевдонимом к модулю ops соединения, заданного по умолчанию, пространственной базы данных.

Пользователи, которые больше полагались на недокументированные модули и объекты в рамках django.contrib.gis.db.backend, а не на абстракции, предоставляемые SpatialBackend, должны модефицировать свой код. Вот пример import, который будет работать в версии 1.1 и ниже:

from django.contrib.gis.db.backend.postgis import PostGISAdaptor

необходимо бы изменить:

from django.db import connection
PostGISAdaptor = connection.ops.Adapter

Модели SpatialRefSys и GeometryColumns

В предыдущих версиях GeoDjango, в django.contrib.gis.db.models были модели SpatialRefSys и GeometryColumns для запроса OGC пространственных таблиц метаданных spatial_ref_sys и geometry_columns, соответственно.

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

Примечание

Поскольку структура таблицы OGC пространственных таблиц метаданных отличается от пространственных баз данных, модели SpatialRefSys и GeometryColumns больше не могут ассоциироваться с именем приложения gis. Таким образом, никакие модели не будут возвращаться при использовании метода get_models вот пример:

>>> from django.db.models import get_app, get_models
>>> get_models(get_app('gis'))
[]

Чтобы получить правильный SpatialRefSys и GeometryColumns для вашей пространственной базы данных, используйте методы, предоставляемые пространственным бэкэндом:

>>> from django.db import connections
>>> SpatialRefSys = connections['my_spatialite'].ops.spatial_ref_sys()
>>> GeometryColumns = connections['my_postgis'].ops.geometry_columns()

Примечание

При использовании моделей, возвращаемых из метода spatial_ref_sys() и geometry_columns() вам все равно придется использовать правильный псевдоним базы данных при выполнении запросов на нестандартные соединения. Иными словами, для того, чтобы модели в приведенном выше примере использовали правильную базу данных:

sr_qs = SpatialRefSys.objects.using('my_spatialite').filter(...)
gc_qs = GeometryColumns.objects.using('my_postgis').filter(...)

Языковой код no

Применяемый в данный момент языковой код Norwegian Bokmål no заменён более распространенным языковым кодом nb.

 

Оригинал статьи на  www.docs.djangoproject.com

Перевод хостинг КОМТЕТ komtet.ru