Поддержка нескольких баз данных¶

В Django 1.2 добавлена ​​возможность использовать более одной базы данных в вашем проекте Django. Запросы могут быть выполнены в конкретной базе данных с помощью метода using() для объектов QuerySet. Отдельные объекты можно сохранить в определенной базе данных, указав аргумент using при вызове save().

Проверка модели¶

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

Улучшенная защита CSRF¶

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

Структура сообщений¶

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

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

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

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

Если вы предоставляете собственный бэкэнд аутентификации с параметром Supports_anonymous_user, установленным в значение True, AnonymousUser проверит бэкэнд на наличие разрешений, как это уже сделал Пользователь. Это полезно для централизации обработки разрешений — приложения всегда могут делегировать вопрос о том, разрешено или нет что-то, серверной части авторизации/аутентификации. Дополнительную информацию см. в документах по аутентификации.

Смягченные требования к именам пользователей¶

Встроенное поле User модели username теперь допускает более широкий диапазон символов, включая символы @, +, . и -.

Серверная часть электронной почты¶

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

Это также упрощает отладку отправки почты. Django поставляется с реализациями серверной части, которые позволяют отправлять электронную почту в file, в console или в memory. Вы даже можете настроить так, чтобы вся электронная почта была выброшена.

«Умный» тег if¶

Тег if был обновлен и стал гораздо более мощным. Во-первых, мы добавили поддержку операторов сравнения. Вам больше не придется вводить:

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

Теперь вы можете сделать это:

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

На самом деле нет причин больше использовать {% ifequal %} или {% ifnotequal %}, если только вы не относитесь к ностальгическому типу.

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

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

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

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

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

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

Загрузчики шаблонов на основе классов¶

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

Все загрузчики шаблонов, поставляемые с Django <template-loaders>, были портированы на новый API, но они по-прежнему реализуют API, основанный на функциях, а механизм ядра шаблонов по-прежнему принимает загрузчики, основанные на функциях (встроенные или сторонние), поэтому нет немедленной необходимости изменять настройку TEMPLATE_LOADERS в существующих проектах, все будет работать, если вы оставите его нетронутым вплоть до выпуска Django 1.3 включительно.

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

Натуральные ключи в светильниках¶

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

Быстрый провал тестов¶

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

БигИнтегерФилд¶

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

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

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

readonly_fields в ModelAdmin¶

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

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

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

Синдикация каналов в виде просмотров¶

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

ГеоДжанго¶

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

• 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. Новые функции включают поддержку типа географии и включение запросов расстояния с неточечной геометрией в географических системах координат.

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

Методы force_rhr(), reverse_geom() и geohash(), GeoQuerySet являются новыми.

Интерфейс GEOS был обновлен для использования функций потокобезопасной библиотеки C, если они доступны на платформе.

Интерфейс GDAL теперь позволяет пользователю устанавливать spatial_filter для объектов, возвращаемых при итерации Layer.

Наконец, Документация GeoDjango теперь включена в состав Django и больше не размещается отдельно на geodjango.org.

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

Если в браузере пользователя включен JavaScript, интерфейс для встроенных объектов в панели администратора теперь позволяет динамически добавлять и удалять встроенные объекты. Пользователи без браузеров с поддержкой JavaScript не увидят изменений в поведении встроенных объектов.

Новые символы спецификатора формата тега шаблона now: c и u¶

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

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

CSRF-защита¶

Мы внесли большие изменения в способ работы защиты CSRF, подробно описанный в документации CSRF. Вот основные изменения, о которых вам следует знать:

• CsrfResponseMiddleware и CsrfMiddleware устарели и будут полностью удалены в Django 1.4 в пользу тега шаблона, который следует вставлять в формы.

• Все приложения-участники используют декоратор csrf_protect для защиты представления. Для этого необходимо использовать в шаблоне тег шаблона csrf_token. Если вы использовали пользовательские шаблоны для дополнительных представлений, НЕОБХОДИМО ПРОЧИТАТЬ ИНСТРУКЦИИ ПО ОБНОВЛЕНИЮ, чтобы исправить эти шаблоны.

  Документация удалена

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

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

• Весь CSRF перенесен из вклада в ядро ​​(с обратно совместимым импортом в старые местоположения, которые устарели и перестанут поддерживаться в Django 1.4).

get_db_prep_*() методы для Field¶

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

class CustomModelField(models.Field):
    ...

    def db_type(self): ...

    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 db_type(self, connection): ...

    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): ...

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

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

Мы предоставили функции преобразования, которые прозрачно преобразуют функции, соответствующие старому прототипу, в функции, совместимые с новым прототипом. Однако эти функции преобразования будут удалены в Django 1.4, поэтому вам следует как можно скорее обновить определения «Поля», чтобы использовать новый прототип.

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

Теги шаблонов с отслеживанием состояния¶

Теги шаблонов, которые хранят состояние рендеринга в своем подклассе Node, всегда были уязвимы для безопасности потоков и других проблем; однако, начиная с Django 1.2, они также могут вызывать проблемы при использовании с новым кэшированным загрузчиком шаблонов.

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

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

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

с subtemplate.html, который гласит:

{% cycle 'even' 'odd' %}

Используя непотокобезопасный рендерер до 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. Раньше эти декораторы можно было использовать как в функциях (где первый аргумент — «запрос»), так и в методах (где первый аргумент — «я», а второй аргумент — «запрос»). К сожалению, в коде, поддерживающем это, были обнаружены недостатки: он работает только в ограниченных случаях и выдаёт ошибки, которые очень сложно отладить, когда он не работает.

По этой причине поведение «автоматической адаптации» было удалено, и если вы используете эти декораторы для методов, вам нужно будет вручную применить 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 он больше не принимает «и», «или» и «не» в качестве допустимых имен переменных. Раньше эти строки можно было использовать в качестве имен переменных. Теперь статус ключевого слова всегда применяется, и код шаблона, такой как {% if not %} или {% if and %}, будет выдавать TemplateSyntaxError. Кроме того, in — это новое ключевое слово, поэтому оно не является допустимым именем переменной в этом теге.

ЛенивыйОбъект¶

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

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

Если вы использовали LazyObject в своем коде и реализовали метод get_all_members() для обернутых объектов, вам необходимо внести пару изменений:

Во-первых, если у вашего класса нет особых требований к самоанализу (т. е. вы не реализовали __getattr__() или другие методы, позволяющие использовать атрибуты, не обнаруживаемые обычными механизмами), вы можете просто удалить метод get_all_members(). Реализация по умолчанию в LazyObject будет работать правильно.

Если у вас более сложные требования к самоанализу, сначала переименуйте метод get_all_members() в __dir__(). Это стандартный метод самоанализа для Python 2.6 и выше. Если вам требуется поддержка версий Python ниже 2.6, добавьте в класс следующий код:

__members__ = property(lambda self: self.__dir__())

__dict__ для экземпляров модели¶

Исторически атрибут __dict__ экземпляра модели содержал только атрибуты, соответствующие полям модели.

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

Код состояния завершения выполнения теста¶

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

Кодирование файлов cookie¶

Чтобы исправить ошибки с файлами cookie в Internet Explorer, Safari и, возможно, других браузерах, наша кодировка значений файлов cookie была изменена таким образом, чтобы запятая и точка с запятой рассматривались как небезопасные символы и поэтому кодировались как \054 и \073 соответственно. Это может привести к обратной несовместимости, особенно если вы храните запятую или точку с запятой в файлах cookie и имеете код JavaScript, который анализирует и манипулирует значениями файлов 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. Единственный случай, когда это может стать проблемой, — это если вы ожидаете, что при повторении BooleanField будет напечатано «1» или «0».

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

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

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

Начиная с версии 1.2, значение по умолчанию для max_num было изменено на None, и FormSets будет различать значение None и значение 0. Значение «Нет» указывает, что ограничения на количество форм не налагаются; значение 0 указывает, что должно быть введено максимум 0 форм. Это не обязательно означает, что никакие формы не будут отображаться — более подробную информацию см. в документации ModelFormSet <model-formsets-max-num>`.

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

email_re¶

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

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

До Django 1.2 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",
    }
}

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

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

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

Серверная часть базы данных postgresql¶

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

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

Промежуточное ПО для перезаписи ответов CSRF¶

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

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

SMTPConnection¶

Класс SMTPConnection устарел в пользу общего API-интерфейса электронной почты. Старый код, который явно создавал экземпляр SMTPConnection:

from django.core.mail import SMTPConnection

connection = SMTPConnection()
messages = get_notification_email()
connection.send_messages(messages)

… теперь следует вызвать get_connection(), чтобы создать экземпляр общего соединения электронной почты:

from django.core.mail import get_connection

connection = get_connection()
messages = get_notification_email()
connection.send_messages(messages)

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

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, и возвращаются к настройкам по умолчанию, если установлено значение True. Ложь.

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

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")

То же самое относится и к глобальным переменным, найденным в django.forms.fields:

• DEFAULT_DATE_INPUT_FORMATS

• DEFAULT_TIME_INPUT_FORMATS

• DEFAULT_DATETIME_INPUT_FORMATS

Используйте django.utils.formats.get_format(), чтобы получить соответствующие форматы.

Средства запуска тестов на основе функций¶

Django 1.2 меняет инструменты запуска тестов, чтобы использовать подход на основе классов. Старые средства запуска тестов на основе функций по-прежнему будут работать, но их следует обновить для использования новых средств запуска тестов на основе классов <topics-testing-test_runner>`.

Подача в django.contrib.syndiction.feeds¶

Класс django.contrib.syndiction.feeds.Feed был заменен классом django.contrib.syndiction.views.Feed. Старый классfeeds.Feed устарел и будет удален в Django 1.4.

Новый класс имеет почти идентичный API, но позволяет использовать экземпляры в качестве представлений. Например, рассмотрим использование старой структуры в следующем 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, эти каналы можно развернуть непосредственно в виде представлений:

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()», то класс «LatestEntries» часто не нужно будет модифицировать, за исключением создания подкласса нового класса Feed. Исключением является случай, когда Django автоматически определяет имя шаблона, который будет использоваться для отображения элементов описания и заголовка канала (если вы не указали атрибуты title_template и description_template). Вы должны убедиться, что вы всегда указываете атрибуты title_template и description_template или предоставляете методы item_title() и item_description().

Однако LatestEntriesByCategory использует метод get_object() с аргументом bits для указания конкретной категории для отображения. В новом классе Feed метод 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 напрямую. Вместо того, чтобы просто принимать необязательный аргумент url, он теперь принимает два аргумента: объект, возвращаемый его собственным методом get_object(), и текущий объект request.

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

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

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

Идентификаторы технических сообщений¶

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

ГеоДжанго¶

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

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

from django.db import connection

PostGISAdaptor = connection.ops.Adapter

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

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

Код языка нет¶

Используемый в настоящее время языковой код норвежского букмола «no» заменяется более распространенным языковым кодом «nb».

Загрузчики шаблонов на основе функций¶

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