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

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

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

Эта функция из пакета django-transaction-hooks была интегрирована в Django.

Проверка паролей ¶

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

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

По умолчанию проверка не выполняется и принимаются все пароли. Если вы не добавите контент AUTH_PASSWORD_VALIDATORS , вы не увидите никаких изменений. В новых проектах, созданных с использованием шаблона по startproject умолчанию, включен простой набор валидаторов. Чтобы включить базовую проверку в формах аутентификации Django в вашем проекте, вы можете определить, например:

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

Подробнее см. Проверка паролей .

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

Django теперь поставляется с классами подмешать AccessMixin , LoginRequiredMixin , PermissionRequiredMixin и UserPassesTestMixin для обеспечения функциональных возможностей django.contrib.auth.decorators для представлений , основанных на классах. Эти классы взяты из проекта django-braces или вдохновлены им .

Однако между реализациями Django и django-braces ” есть несколько различий :

• Атрибут raise_exception может быть только True или False . Исключения или настраиваемые исполняемые объекты не поддерживаются.
• Метод handle_no_permission() не принимает никаких параметров request . Текущий запрос доступен в формате self.request .
• Пользовательская функция test_func() из UserPassesTestMixin не принимает какого - либо параметра user . Текущий запрос доступен в формате self.request.user .
• Атрибут permission_required принимает строку (определяющую одно разрешение) или список строк (определяя несколько разрешений), которые должны быть предоставлены для разрешения доступа.
• Новый атрибут permission_denied_message позволяет передать сообщение об исключении PermissionDenied .

Новый стиль для contrib.admin ¶

Интерфейс администратора имеет новый, современный, солидный вид с новыми значками SVG, которые отлично смотрятся на экранах с высокой плотностью пикселей. Это всегда гарантирует полнофункциональную работу с браузерами YUI A-level . Старые браузеры иногда могут работать в приемлемом ухудшенном режиме.

Параллельное выполнение тестов ¶

Теперь test команда поддерживает --parallel возможность параллельного запуска тестов проекта в нескольких процессах.

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

Эта опция включена по умолчанию для собственного набора тестов Django, если:

• операционная система поддерживает его (все кроме Windows)
• ядро базы данных поддерживает его (все встроенные движки, кроме Oracle)

Незначительные особенности ¶

API ядра СУБД ¶

• Некоторые новые тесты полагаются на способность движка проверять значения столбцов по умолчанию (возвращая результат в Field.default ). Вы можете установить функциональность базы данных can_introspect_default для False если ваш двигатель не позволяет этот самоанализ. Вы можете ознакомиться с реализацией движков, включенных в Django, для справки ( # 24245 ).

• Не рекомендуется регистрировать глобальный адаптер или преобразователь на уровне модуля DB-API для обработки информации о часовом поясе значений, datetime передаваемых в качестве параметров запроса или возвращаемых в качестве результатов запроса с базами данных, которые не поддерживают часовые пояса. Это может вызвать конфликты с другими библиотеками.

  Рекомендуемый способ добавить часовой пояс к значениям, datetime полученным из базы данных, - это зарегистрировать преобразователь для полей DateTimeField в DatabaseOperations.get_db_converters() .

  Функциональность базы данных needs_datetime_string_cast была удалена. Механизмы базы данных, которые его определяют, должны вместо этого зарегистрировать преобразователь, как описано выше.

• Методы DatabaseOperations.value_to_db_<type>() были переименованы adapt_<type>field_value() для единообразия с методами convert_<type>field_value() .

• Чтобы использовать новый запрос date , сторонним механизмам баз данных может потребоваться реализовать этот метод DatabaseOperations.datetime_cast_date_sql() .

• Метод DatabaseOperations.time_extract_sql() был добавлен. Он вызывает существующий метод date_extract_sql() . Этот метод перегружен механизмом SQLite для добавления ежечасных запросов (час, минута, секунда) в поля TimeField . Некоторым сторонним механизмам баз данных может потребоваться сделать то же самое.

• Метод DatabaseOperations.datetime_cast_sql() (не путать с DatabaseOperations.datetime_cast_date_sql() упомянутым выше) был удален. Этот метод использовался для форматирования дат в Oracle задолго до версии 1.0, но не был перегружен другими встроенными механизмами в течение многих лет и не вызывался из других мест в мире. код или тесты Django.

• Для поддержки распараллеливания тестов метод должен быть реализован DatabaseCreation._clone_test_db() и определен . Может потребоваться корректировка .DatabaseFeatures.can_clone_databases = True DatabaseCreation.get_test_db_clone_settings()

Настройки по умолчанию, которые были кортежами, теперь представлены списками ¶

По умолчанию django.conf.global_settings включены как списки, так и кортежи. Все настройки, которые раньше были кортежами, теперь являются списками.

Атрибут is_usable загрузчиков шаблонов был удален ¶

Загрузчики шаблонов Django ранее требовали наличия атрибута is_usable . Если загрузчик был настроен в настройках шаблона и этот атрибут был действительным False , загрузчик игнорировался. На практике это использовалось только загрузчиком «яйца», чтобы определить, были ли установлены инструменты установки. Этот атрибут is_usable теперь удален, и загрузчик "яиц" не работает во время выполнения, если не установлены инструменты установки.

Прямое присвоение набора связанных объектов ¶

Прямое присвоение связанных объектов в ORM, используемом для выполнения, clear() за которым следует вызов add() . Это вызвало излишне большие изменения данных и не позволило использовать m2m_changed сигнал для отслеживания отдельных изменений в отношениях «многие ко многим».

Прямое назначение теперь основывается на новом set() методе связанных менеджеров, который по умолчанию обрабатывает только изменения между существующим связанным набором и новым назначенным. Предыдущее поведение можно восстановить, заменив прямое присвоение вызовом set() аргументу ключевого слова clear=True .

ModelForm и, следовательно ModelAdmin , внутренне полагаются на прямую атрибуцию для отношений "многие ко многим" и поэтому теперь используют новое поведение.

Загрузчики шаблонов на основе файловой системы более точно улавливают исключения ¶

При использовании загрузчиков шаблонов filesystem.Loader или app_directories.Loader предыдущие версии Django генерировали ошибку, TemplateDoesNotExist если источник шаблона существовал, но был нечитаемым. Это могло произойти при различных обстоятельствах, например, если у Django не было разрешений на открытие файла или если источником шаблона был каталог. С этого момента Django скрывает исключение только в том случае, если источник шаблона не существует. Во всех остальных случаях IOError будет сгенерировано исходное исключение .

Перенаправления HTTP больше не обязательно должны быть абсолютными URI ¶

Относительные перенаправления больше не преобразуются в абсолютные URI. RFC 2616 требует, чтобы заголовокLocation ответов перенаправления был абсолютным URI, но этот стандарт был замененRFC 7231, который разрешает относительные URILocation , таким образом признавая реальную практику пользовательских агентов, почти все из которых принимают такой способ действий.

Следовательно, ожидаемые URL-адреса, передаваемые на, assertRedirects как правило, больше не должны включать в себя часть URL-адресов схемы и домена. Например, следует заменить на (если перенаправление специально не содержит абсолютный URL).self.assertRedirects(response, 'http://testserver/some-url/') self.assertRedirects(response, '/some-url/')

В редком случае, когда вам нужно старое поведение (обнаруженное в старой версии Apache, где mod_scgi относительное перенаправление интерпретируется как «внутреннее перенаправление»), вы можете восстановить его, написав специальное промежуточное ПО:

class LocationHeaderFix(object):
    def process_response(self, request, response):
        if 'Location' in response:
            response['Location'] = request.build_absolute_uri(response['Location'])
        return response

Прекращение поддержки PostgreSQL 9.0 ¶

Поддержка PostgreSQL 9.0 в апстрим-проектах закончилась в сентябре 2015 года. В результате Django 1.9 определила версию 1.9 как минимальную официально поддерживаемую версию PostgreSQL.

Прекращение поддержки Oracle 11.1 ¶

Поддержка Oracle 11.1 вышестоящим проектом закончилась в августе 2015 года. Таким образом, Django 1.9 определил версию 11.2 как минимальную официально поддерживаемую версию Oracle.

Массовое добавление поведения метода add() менеджера отношений ¶

Для повышения производительности, методы add() менеджеров отношений , созданных полей ForeignKey и GenericForeignKey изменили свое поведение из ряда вызовов Model.save() на один вызов QuerySet.update() . Это изменение подразумевает, что сигналы pre_save и post_save больше не отправляются в таких ситуациях. Вы можете использовать именованный параметр, bulk=False чтобы вернуться к старому поведению.

Удаление LoaderOrigin и StringOrigin шаблоны ¶

В предыдущих версиях Django при инициализации механизма шаблонов debug=True экземпляр django.template.loader.LoaderOrigin или django.template.base.StringOrigin устанавливался в качестве исходного атрибута объекта шаблона. Эти классы были объединены, Origin и теперь атрибут устанавливается всегда, независимо от настройки отладки движка. Для минимального уровня обратной совместимости старые имена классов будут сохраняться как псевдонимы нового класса Origin до Django 2.0.

Изменения в конфигурации ведения журнала по умолчанию ¶

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

• console : фильтруется на INFO уровне и активен, только если DEBUG=True .
• mail_admins : фильтруется на ERROR уровне и активен, только если DEBUG=False .

Если вы не переопределите ведение журнала Django по умолчанию, вы должны увидеть только минимальные изменения в поведении, но, например, вы можете увидеть некоторые новые сообщения в консоли runserver .

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

Подробности HttpRequest в отчетах об ошибках ¶

Избыточно отображать полную информацию о запросе HttpRequest всякий раз, когда он появлялся в виде переменной стека вызовов в HTML-версии страницы отладки и сообщения об ошибке. Таким образом, HTTP-запрос теперь отображается в том же стандартном представлении, что и другие переменные ( repr(request) ). В результате были удалены ExceptionReporterFilter.get_request_repr() недокументированные метод и функция django.http.build_request_repr() .

Содержимое текстовой версии электронного письма было изменено, чтобы обеспечить трассировку вызовов той же структуры, что и в случае запросов AJAX. Подробности трассировки вызовов производятся методом ExceptionReporter.get_traceback_text() .

Удалены адаптеры и конвертеры глобального часового пояса для объектов даты и времени ¶

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

• Настройка USE_TZ содержит True .
• База данных - это SQLite, MySQL, Oracle или другая сторонняя база данных, которая не поддерживает часовые пояса. Если сомневаетесь, вы можете проверить значение connection.features.supports_timezones .
• Код запрашивает базу данных вне ORM, обычно с помощью .cursor.execute(sql, params)

Если вы передаете datetime в такие запросы параметры часового пояса, вы должны превратить их в наивные даты / время в UTC:

from django.utils import timezone
param = timezone.make_naive(param, timezone.utc)

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

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

from django.utils import timezone
value = timezone.make_aware(value, timezone.utc)

В этом нет необходимости, если вы запрашиваете базу данных через ORM, даже если вы используете запросы raw() . ORM отвечает за управление информацией о часовом поясе.

Модули тегов шаблонов импортируются при настройке шаблонов ¶

Теперь движок DjangoTemplates переходит к обнаружению шаблонных модулей маяков, установленных во время его создания. Это изменение позволяет библиотеки быть активированы явно с помощью ключа 'libraries' из OPTIONS в определении двигателя DjangoTemplates . Возможные ошибки импорта или синтаксиса в модулях тегов шаблона приводят к быстрому сбою во время создания экземпляра, а не при первой компиляции шаблона с тегом .{% load %}

Удаление django.template.base.add_to_builtins() ¶

Несмотря на то, что это был частный API, проекты часто использовали его, add_to_builtins() чтобы сделать теги шаблонов и фильтры доступными без необходимости использовать тег . Этот API формализован. Теперь проекты должны включать в себя библиотеку , используя ключ к при определении двигателя .{% load %} 'builtins' OPTIONS DjangoTemplates

Результат simple_tag теперь всегда проходит через conditional_escape ¶

Как правило, теги шаблона не экранируют свое содержимое автоматически, и это поведение задокументировано . Для таких тегов inclusion_tag это не проблема, потому что включенный шаблон будет выполнять автоматическое экранирование. Для assignment_tag() вывода будет экранирован, когда он используется в качестве переменной в шаблоне.

Однако для предполагаемых случаев использования simple_tag очень легко получить неверный HTML-код и, следовательно, создать риск XSS-уязвимости. Например :

@register.simple_tag(takes_context=True)
def greeting(context):
    return "Hello {0}!".format(context['request'].user.first_name)

В предыдущих версиях Django это считалось XSS-уязвимостью, потому что от нее user.first_name не удалось избежать.

В Django 1.9 это исправлено: если контекст шаблона имеет autoescape=True (по умолчанию), simple_tag результат функции тега будет передаваться как conditional_escape() .

simple_tag Вот несколько рекомендаций, которые помогут исправить теги :

• Любой код, создающий HTML, должен использовать либо систему шаблонов, либо format_html() .
• Если результат тега simple_tag необходимо экранировать, используйте escape() или conditional_escape() .
• Если вы абсолютно уверены, что создаете HTML-код из надежного источника (например, поля CMS, в котором хранится HTML-код, введенный администраторами), вы можете отметить его как таковой, используя mark_safe() .

Теги, соответствующие этим правилам, будут правильными и безопасными независимо от того, работают ли они с Django 1.9+ или более ранними версиями.

Paginator.page_range ¶

Paginator.page_range теперь итератор вместо списка.

В версиях Django до 1.8 Paginator.page_range возвращал объект list в Python 2 и объект range в Python 3. Django 1.8 по-прежнему возвращает список, но итератор более эффективен.

Существующий код, который зависит от конкретных функций объектов list , таких как индексация, может позаботиться о преобразовании итератора в list функцию list() .

Неявное выполнение запроса __in о QuerySet удален ¶

В предыдущих версиях такие запросы, как:

Model.objects.filter(related_id=RelatedModel.objects.all())

были неявно преобразованы в:

Model.objects.filter(related_id__in=RelatedModel.objects.all())

который создал код SQL для стиля ."related_id IN (SELECT id FROM ...)"

__in Неявная операция больше не выполняется, поэтому SQL «IN» теперь равен «=», и если подзапрос возвращает несколько результатов, большинство баз данных выдаст ошибку.

Браузеры, поддерживаемые contrib.admin ¶

Сайт администрирования больше не поддерживает версии Internet Explorer 8 и старше, так как срок службы этих браузеров официально закончился.

Изображения и стили CSS, поддерживающие Internet Explorer 6 и 7, были удалены. Значки PNG и GIF были заменены значками SVG, которые не поддерживаются Internet Explorer 8 или более ранними версиями.

Библиотека jQuery, встроенная в админку, была обновлена ​​с версии 1.11.2 до 2.1.4. jQuery 2.x имеет тот же API, что и jQuery 1.x, но не поддерживает Internet Explorer 6, 7 или 8, что обеспечивает более высокую производительность и меньший размер файла. Если вам нужна поддержка IE8 и вы также должны использовать последнюю версию Django, вы можете заменить административную копию jQuery своей собственной, создав приложение Django с такой структурой:

app/static/admin/js/vendor/
    jquery.js
    jquery.min.js

SyntaxError при установке Django setuptools 5.5.x ¶

При установке Django 1.9 или 1.9.1 с помощью setuptools 5.5.x вы увидите:

Compiling django/conf/app_template/apps.py ...
  File "django/conf/app_template/apps.py", line 4
    class {{ camel_case_app_name }}Config(AppConfig):
          ^
SyntaxError: invalid syntax

Compiling django/conf/app_template/models.py ...
  File "django/conf/app_template/models.py", line 1
    {{ unicode_literals }}from django.db import models
                             ^
SyntaxError: invalid syntax

Эти ошибки можно игнорировать (Django все равно установится нормально), но вы можете избежать их, обновив setuptools до более новой версии. Если вы используете pip, вы можете обновить pip, используя который также обновит инструменты установки. Это решено в более поздних версиях Django, как описано в примечаниях к выпуску Django 1.9.2 .python -m pip install -U pip

Разное ¶

• Статические файлы jQuery contrib.admin перемещены в vendor/jquery подкаталог.
• Текст, отображаемый для пустых столбцов в list_display ячейках административного списка изменений, изменился с (None) (или его переведенного эквивалента) на - (тире).
• django.http.responses.REASON_PHRASES и django.core.handlers.wsgi.STATUS_CODE_TEXT были удалены. Вместо этого используйте Python stdlib: http.client.responses для Python 3 и httplib.responses для Python 2.
• ValuesQuerySet и ValuesListQuerySet были удалены.
• admin/base.html Шаблон больше не устанавливает window.__admin_media_prefix__ или window.__admin_utc_offset__ . Ссылки на изображения в JavaScript, которые использовали это значение для создания абсолютных URL-адресов, были перемещены в CSS для упрощения настройки. Смещение UTC хранится в атрибуте данных <body> тега.
• CommaSeparatedIntegerField Валидация-была усовершенствована , чтобы запретить выгоды , как ',' , ',1' и '1,,2' .
• Инициализация формы перенесена из ProcessFormView.get() метода в новый FormMixin.get_context_data() метод. Это может быть обратно несовместимым, если вы переопределили get_context_data() метод без вызова super() .
• Поддержка PostGIS 1.5 прекращена.
• Поле django.contrib.sites.models.Site.domain было определено как unique .
• Чтобы обеспечить изоляцию тестов, запросы к базе данных больше не разрешены по умолчанию в SimpleTestCase тестах. Вы можете отключить это поведение, установив allow_database_queries атрибут class в True свой тестовый класс.
• ResolverMatch.app_name был изменен, чтобы содержать полный путь пространства имен в случае вложенных пространств имен. Для согласованности с ResolverMatch.namespace пустым значением теперь является пустая строка вместо None .
• Для усиления безопасности ключи сеанса должны содержать не менее 8 символов.
• Приватная функция django.utils.functional.total_ordering() удалена. Он содержал обходной путь для functools.total_ordering() ошибки в версиях Python старше 2.7.3.
• Сериализация XML (через dumpdata или через структуру синдикации), используемая для вывода любых полученных символов. Теперь, если сериализуемый контент содержит какие-либо управляющие символы, недопустимые в стандарте XML 1.0, сериализация завершится ошибкой с расширением ValueError .
• CharField теперь по умолчанию удаляет ввод начальных и конечных пробелов. Это можно отключить, установив для нового strip аргумента значение False .
• Текст шаблона, который переведен и использует два или более последовательных знака процента, например "%%" , может иметь новый msgid после makemessages выполнения (скорее всего, перевод будет помечен как нечеткий). Новый msgid будет отмечен ."#, python-format"
• Если ни request.current_app ни Context.current_app не заданы, url тег шаблона теперь будет использовать пространство имен текущего запроса. Установите request.current_app значение, None если вы не хотите использовать подсказку пространства имен.
• SILENCED_SYSTEM_CHECKS Установка в настоящее время заглушает сообщения всех уровней. Раньше ERROR на консоль выводились сообщения уровня или выше.
• FlatPage.enable_comments Поле удаляется из , FlatPageAdmin как он не используется приложением. Если ваш проект или стороннее приложение использует его, создайте собственный ModelAdmin, чтобы добавить его обратно.
• Возвращаемое значение setup_databases() и первый аргумент teardown_databases() изменены. Раньше они были кортежами. Теперь они просто первый элемент .(old_names, mirrors) old_names
• По умолчанию LiveServerTestCase пытается найти доступный порт в диапазоне 8081-8179 вместо того, чтобы просто пробовать порт 8081.
• Система проверяет ModelAdmin теперь экземпляры, а не классы.
• Частный API для применения смешанных планов миграции был удален из соображений производительности. Смешанные планы состоят из списка миграций, в которых одни применяются, а другие не применяются.
• Связанные классы дескрипторов объекта модели в django.db.models.fields.related (частный API) перемещаются из related модуля в related_descriptors и переименовываются следующим образом:
  • ReverseSingleRelatedObjectDescriptor является ForwardManyToOneDescriptor
  • SingleRelatedObjectDescriptor является ReverseOneToOneDescriptor
  • ForeignRelatedObjectsDescriptor является ReverseManyToOneDescriptor
  • ManyRelatedObjectsDescriptor является ManyToManyDescriptor
• Если вы реализуете настраиваемое handler404 представление, оно должно возвращать ответ с кодом состояния HTTP 404. Используйте HttpResponseNotFound или переходите status=404 на HttpResponse . В противном случае APPEND_SLASH с DEBUG=False .

assignment_tag() ¶

В Django 1.4 добавлен assignment_tag помощник, упрощающий создание тегов шаблона, в которых результаты хранятся в переменной шаблона. simple_tag() Помощник приобрел такую же способность, что делает assignment_tag устаревшими. Теги, которые используют, assignment_tag должны быть обновлены для использования simple_tag .

{% cycle %} синтаксис с аргументами, разделенными запятыми ¶

cycle Тег поддерживает подчиненный старый синтаксис из предыдущих версий Django:

{% cycle row1,row2,row3 %}

Его синтаксический анализ вызвал ошибки с текущим синтаксисом, поэтому поддержка старого синтаксиса будет удалена в Django 1.10 после ускоренного прекращения поддержки.

ForeignKey и OneToOneField on_delete аргумент ¶

Чтобы повысить осведомленность о каскадном удалении модели, в Django 2.0 потребуется on_delete аргумент ForeignKey и OneToOneField .

Обновите модели и существующие миграции, чтобы явно указать аргумент. Поскольку значение по умолчанию - models.CASCADE добавить on_delete=models.CASCADE ко всем ForeignKey и OneToOneField s, которые не используют другой параметр. Вы также можете передать его в качестве второго позиционного аргумента, если вас не волнует совместимость со старыми версиями Django.

Field.rel изменения ¶

Field.rel и его методы и атрибуты были изменены, чтобы соответствовать API связанных полей. Field.rel Атрибут переименован remote_field и многие из его методов и атрибутов, либо изменить или переименовать.

Цель этих изменений - предоставить задокументированный API для полей отношений.

GeoManager и GeoQuerySet пользовательские методы ¶

Все пользовательские GeoQuerySet методы ( area() , distance() , gml() ...) - были-были заменены географическими эквивалентными выражениями в аннотации (см новых функций). Следовательно, необходимость настраивать пользовательские GeoManager модели для ГИС-моделей теперь устарела. Как только ваш код не вызывает ни одного из устаревших методов, вы можете просто удалить строки из своих моделей.objects = GeoManager()

Изменились API загрузчика шаблонов ¶

Загрузчики шаблонов Django были обновлены, чтобы разрешить рекурсивное расширение шаблона. Это изменение потребовало нового API загрузчика шаблонов. Старые load_template() и load_template_sources() методы в настоящее время не рекомендуется. Подробности о новом API можно найти в документации загрузчика шаблонов .

Передача 3-кортеж или app_name к include() ¶

Часть пространства имен экземпляра при передаче кортежа в качестве аргумента include() была заменена передачей namespace аргумента в include() . Например:

polls_patterns = [
     url(...),
]

urlpatterns = [
    url(r'^polls/', include((polls_patterns, 'polls', 'author-polls'))),
]

СТАНОВИТСЯ:

polls_patterns = ([
     url(...),
], 'polls')  # 'polls' is the app_name

urlpatterns = [
    url(r'^polls/', include(polls_patterns, namespace='author-polls')),
]

app_name Аргумент include() был заменен путем пропускания 2-кортеж (как указано выше), или передавая объект или модуль с app_name атрибутом (как показано ниже). Если app_name задано этим новым способом, namespace аргумент больше не требуется. По умолчанию будет установлено значение app_name . Например, шаблоны URL-адресов в руководстве изменены с:

urlpatterns = [
    url(r'^polls/', include('polls.urls', namespace="polls")),
    ...
]

чтобы:

urlpatterns = [
    url(r'^polls/', include('polls.urls')),  # 'namespace="polls"' removed
    ...
]

app_name = 'polls'  # added
urlpatterns = [...]

Это изменение также означает, что старый способ включения AdminSite экземпляра устарел. Вместо этого перейдите admin.site.urls непосредственно к django.conf.urls.url() :

from django.conf.urls import url
from django.contrib import admin

urlpatterns = [
    url(r'^admin/', admin.site.urls),
]

При установке пространства имен экземпляра требуется пространство имен приложения URL ¶

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

current_app параметр для contrib.auth просмотров ¶

Все представления django.contrib.auth.views имеют следующую структуру:

def view(request, ..., current_app=None, ...):

    ...

    if current_app is not None:
        request.current_app = current_app

    return TemplateResponse(request, template_name, context)

Начиная с Django 1.8, current_app устанавливается на request объекте. Для обеспечения согласованности этих взглядов потребует абонента установить current_app на request вместо того , чтобы передать его в отдельный аргумент.

django.contrib.gis.geoip ¶

В django.contrib.gis.geoip2 модуле аннулирует django.contrib.gis.geoip . Новый модуль предоставляет аналогичный API, за исключением того, что он не предоставляет устаревшие методы совместимости API GeoIP-Python.

Разное ¶

• weak Аргумент django.dispatch.signals.Signal.disconnect() является устаревшим , поскольку это не имеет никакого эффекта.
• Этот check_aggregate_support() метод django.db.backends.base.BaseDatabaseOperations устарел и будет удален в Django 2.0. check_expression_support() Вместо этого следует использовать более общие .
• django.forms.extras устарела. Вы можете найти SelectDateWidget в django.forms.widgets (или просто django.forms ) вместо этого.
• Частный API django.db.models.fields.add_lazy_relation() устарел.
• django.contrib.auth.tests.utils.skipIfCustomUser() Декоратор устарела. С изменениями обнаружения тестов в Django 1.6 тесты django.contrib приложений больше не выполняются как часть проекта пользователя. Таким образом, @skipIfCustomUser декоратор больше не нужен для оформления тестов в django.contrib.auth .
• Если вы настроили некоторые обработчики ошибок , сигнатуры представления только с одним параметром запроса устарели. Представления теперь также должны принимать второй exception позиционный параметр.
• django.utils.feedgenerator.Atom1Feed.mime_type И django.utils.feedgenerator.RssFeed.mime_type атрибуты являются устаревшими в пользу content_type .
• Signer теперь выдает предупреждение, если используется недопустимый разделитель. Это станет исключением в Django 1.10.
• django.db.models.Field._get_val_from_obj() устарел в пользу Field.value_from_object() .
• django.template.loaders.eggs.Loader устарел как распространяющие приложения, так как яйца не рекомендуется.
• callable_obj Ключевое слово аргумент SimpleTestCase.assertRaisesMessage() является устаревшим. Вместо этого передайте вызываемый объект как позиционный аргумент.
• allow_tags Атрибут методов ModelAdmin является устаревшим. Используйте format_html() , format_html_join() или mark_safe() При создании возвращаемого значения метода INSTEAD.
• enclosure Ключевое слово аргумент SyndicationFeed.add_item() является устаревшим. Используйте новый enclosures аргумент, который принимает список Enclosure объектов вместо одного.
• django.template.loader.LoaderOrigin И django.template.base.StringOrigin псевдонимы для django.template.base.Origin осуждаются.