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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бэкэнды электронной почты ¶

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

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

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

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

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

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

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

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

Операторы Поддерживаются == , != , < , > , <= , >= , in и , все из которых работают как операторы Python, в дополнение к , и , которые уже были поддержаны.not in 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, API загрузчиков шаблонов был изменен для использования механизмов загрузки шаблонов, которые инкапсулированы в классы Python, а не в функции, единственный метод, доступный до Django 1.1.

Все загрузчики шаблонов, поставляемые с Django , были перенесены в новый 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 во время тестового запуска была улучшена, чтобы запустить плавный выход из тестового запуска, который сообщает подробности тестов, которые были запущены до прерывания.

BigIntegerField ¶

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

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

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

readonly_fields в ModelAdmin ¶

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

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

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

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

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

GeoDjango ¶

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

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

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

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

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

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

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

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

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

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

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

Защита от CSRF ¶

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

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

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

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

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

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

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

get_db_prep_*() методы на Field ¶

До Django 1.2 пользователь Field имел возможность определять несколько функций для поддержки преобразования значений 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 Аргумент используется для указания метода подготовки базы данных , была ли выполнена общая подготовка значения. Если prepared=False для get_db_prep_*() вызовов предоставляется неподготовленное (т. Е. ) Значение , они должны вызывать соответствующие get_prep_*() вызовы для выполнения общей подготовки данных.

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

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

LazyObject ¶

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 атрибут.

Код состояния выхода из программы Test Runner ¶

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

Кодировка файлов 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 . Единственный раз, когда это должно быть проблемой, - это если вы ожидали, что repr a 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 использовал логическое значение, max_num чтобы определить, должно ли быть наложено ограничение на количество сгенерированных форм. Значение по умолчанию 0 означает, что не существует ограничения по умолчанию на количество форм в FormSet.

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

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

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 перемещен из contrib в ядро, и старый импорт устарел, как описано в примечаниях по обновлению.

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

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

• DEFAULT_DATE_INPUT_FORMATS
• DEFAULT_TIME_INPUT_FORMATS
• DEFAULT_DATETIME_INPUT_FORMATS

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

Функциональные средства запуска тестов ¶

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

Feed в django.contrib.syndication.feeds ¶

django.contrib.syndication.feeds.Feed Класс был заменен django.contrib.syndication.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() метод принимает request аргументы и из 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 элемент. Возможно, вам потребуется обновить тесты, чтобы учесть это.

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

ID технических сообщений ¶

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

GeoDjango ¶

Чтобы обеспечить поддержку нескольких баз данных, внутреннее устройство базы данных 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'))
[]

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

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

Код языка no ¶

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

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

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