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

2 сентября 2014 г.

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

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

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

Django 1.7 требует Python 2.7, 3.2, 3.3 или 3.4. Мы настоятельно рекомендуем и официально поддерживаем только последний выпуск каждой серии.

Серия Django 1.6 - последняя, ​​поддерживающая Python 2.6. Django 1.7 - первый выпуск, поддерживающий Python 3.4.

Это изменение должно коснуться только небольшого числа пользователей Django, поскольку сегодня большинство поставщиков операционных систем поставляют Python 2.7 или новее в качестве версии по умолчанию. Однако, если вы все еще используете Python 2.6, вам нужно будет оставаться на Django 1.6, пока вы не обновите свою версию Python. Согласно нашей политике поддержки , Django 1.6 будет продолжать поддерживаться на уровне безопасности до выпуска Django 1.8.

Что нового в Django 1.7

Миграции схемы

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

Миграции описаны в отдельной документации , но некоторые из ключевых функций:

  • syncdb устарел и заменен на migrate . Не волнуйтесь - вызовы по- syncdb прежнему будут работать.

  • Новая команда makemigrations предоставляет простой способ автоматически обнаруживать изменения в ваших моделях и выполнять для них миграции.

    django.db.models.signals.pre_syncdb и django.db.models.signals.post_syncdb устарели и должны быть заменены на pre_migrate и post_migrate соответственно. Эти новые сигналы имеют несколько иные аргументы. Подробности смотрите в документации.

  • Метод allow_syncdb маршрутизаторов базы данных теперь вызывается allow_migrate , но по-прежнему выполняет ту же функцию. Маршрутизаторы с методами по- allow_syncdb прежнему будут работать, но это имя метода устарело, и вы должны изменить его как можно скорее (не требуется ничего, кроме переименования).

  • initial_data фикстуры больше не загружаются для приложений с миграциями; Если вы хотите загрузить исходные данные для приложения, мы предлагаем вам создать миграцию для своего приложения и определить операцию RunPython или RunSQL в operations разделе миграции.

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

  • Не рекомендуется иметь приложение без миграции зависит (есть ForeignKey или ManyToManyField в) приложениях с миграциями.

Переделка загрузки приложения

Исторически приложения Django были тесно связаны с моделями. Синглтон, известный как «кеш приложений», обрабатывает как установленные приложения, так и модели. Модуль моделей использовался в качестве идентификатора приложений во многих API.

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

На сегодняшний день улучшения включают:

  • Приложения могут запускать код при запуске, прежде чем Django сделает что-нибудь еще, с помощью метода ready() их настройки.
  • Ярлыки приложений правильно назначаются шаблонам, даже если они определены вне models.py . Вам больше не нужно явно настраиваться app_label .
  • Можно models.py полностью опустить, если в приложении нет шаблонов.
  • Приложения могут быть переименованы с label помощью атрибута конфигурации приложений, чтобы обойти конфликты именования меток.
  • Название приложений можно настроить в интерфейсе администрирования с помощью атрибута verbose_name конфигураций приложений.
  • Интерфейс администрирования автоматически вызывается autodiscover() при запуске Django. Поэтому вы можете удалить эту строку из своего URLconf.
  • Django импортирует все конфигурации и модели приложений сразу после запуска с помощью простого детерминированного процесса. Это должно упростить диагностику проблем импорта, например циклов импорта.

Новый метод для подклассов полей

Для помощи моторизованным как миграция схемы и позволяют добавление составных ключей легче в будущих версиях Django, то API Field теперь имеет новый обязательный метод: deconstruct() .

Этот метод не принимает аргументов и возвращает кортеж из четырех элементов:

  • name  : Имя атрибута поля в его родительской модели или None, если оно не является частью модели.
  • path  : Путь Python с заостренным синтаксисом к классу этого поля, включая имя класса.
  • args  : позиционные аргументы в виде списка
  • kwargs  : именованные аргументы, как dict

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

Это изменение не должно повлиять на вас, если вы не пишете собственные подклассы Field; в этом случае вам может потребоваться повторно реализовать метод, deconstruct() если ваш подкласс __init__ каким-либо образом изменит сигнатуру метода . Если ваше поле просто наследуется от встроенного поля в Django и не расширяется __init__ , никаких изменений не требуется.

Если вам нужно расширить deconstruct() , хорошее место для начала - встроенные поля в Django ( django/db/models/fields/__init__.py ), потому что несколько полей включают DecimalField и DateField расширяют его, и показывают, как вызвать метод в родительском классе и просто добавить или удалить дополнительные аргументы. ,

Это также означает, что все аргументы поля должны сами быть сериализуемыми; Чтобы узнать, что мы считаем сериализуемыми, и как сделать сериализуемыми собственные классы, см. документацию по сериализации миграции .

Вызов пользовательского метода QuerySet из Manager

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

Хотя это и не задокументировано, эту проблему обычно можно было обойти, создав QuerySet пользовательские методы, чтобы их можно было связать в цепочку; но решение имело ряд недостатков:

  • QuerySet Персонализированные и его индивидуальные методы были потеряны после первого вызова values() или values_list() .
  • Написание кастомного Manager класса по-прежнему необходимо для возврата QuerySet кастомного класса, и все желаемые методы в `` Менеджере '' необходимо перенаправить в QuerySet . Весь процесс противоречил принципу DRY.

Теперь метод класса QuerySet.as_manager() может напрямую создавать Manager с помощью методов QuerySet  :

class FoodQuerySet(models.QuerySet):
    def pizzas(self):
        return self.filter(kind='pizza')

    def vegetarian(self):
        return self.filter(vegetarian=True)

class Food(models.Model):
    kind = models.CharField(max_length=50)
    vegetarian = models.BooleanField(default=False)
    objects = FoodQuerySet.as_manager()

Food.objects.pizzas().vegetarian()

Использование собственного обработчика при обходе обратных отношений

Теперь можно указать собственный обработчик при обходе обратной зависимости:

class Blog(models.Model):
    pass

class Entry(models.Model):
    blog = models.ForeignKey(Blog)

    objects = models.Manager()  # Default Manager
    entries = EntryManager()    # Custom Manager

b = Blog.objects.get(id=1)
b.entry_set(manager='entries').all()

Новая инфраструктура проверки системы

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

Для выполнения системных проверок вы используете команду check управления. Эта команда заменяет старую validate команду управления.

Ярлыки интерфейса администратора поддерживают часовые пояса

Ярлыки «сегодня» и «сейчас» рядом с компонентами ввода даты и времени в интерфейсе администрирования теперь работают в текущем часовом поясе . Раньше они использовали часовой пояс браузера, что могло приводить к тому, что вводились неверные значения, если они не соответствовали часовому поясу текущего сервера.

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

Использование курсоров базы данных в качестве менеджеров контекста

До Python 2.7 курсоры базы данных можно было использовать в качестве диспетчера контекста. Курсор для конкретного движка определяет поведение диспетчера контекста. Поведение поиска магических методов изменилось в Python 2.7, и курсоры больше не могут использоваться в качестве диспетчера контекста.

Django 1.7 позволяет использовать курсор в качестве диспетчера контекста. Другими словами, можно использовать следующее:

with connection.cursor() as c:
    c.execute(...)

вместо того :

c = connection.cursor()
try:
    c.execute(...)
finally:
    c.close()

Пользовательские выражения поиска

Теперь можно писать собственные поисковые запросы и преобразования для ORM. Пользовательские поиски работают так же, как встроенные поисковые запросы Django (например lte , icontains ), в то время как преобразования - это новая концепция.

Класс django.db.models.Lookup предоставляет возможность добавлять операторы поиска для полей модели. В качестве примера можно добавить day_lte для них оператор DateFields .

Класс django.db.models.Transform позволяет преобразовывать значения базы данных перед окончательным преобразованием. Например, можно написать преобразование, year которое извлекает год из значения поля. Преобразования позволяют создавать цепочки. После того, как преобразование year было добавлено DateField , можно, например, выполнить фильтрацию по преобразованному значению qs.filter(author__birthdate__year__lte=1981) .

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

Улучшения обработки ошибок в Form

Form.add_error()

Раньше было две основные модели обработки ошибок в формах:

  • Рычаг a ValidationError От определенных функций (например Field.clean() , Form.clean_<fieldname>() или Form.clean() для ошибок без обращения к полям)
  • Управляйте Form._errors путем нацеливания на конкретное поле Form.clean() или добавления ошибок с помощью внешнего "чистого" метода (например, непосредственно из представления).

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

Новый метод add_error() позволяет добавлять ошибки в определенные поля формы из любого места, не беспокоясь о деталях; например, создание экземпляров django.forms.utils.ErrorList или обработка Form.cleaned_data . Этот новый API заменяет управление Form._errors которым теперь становится частным API.

См. Раздел Очистка и проверка полей, которые зависят друг от друга, в качестве примера использования Form.add_error() .

Метаданные ошибок

Конструктор ValidationError принимает метаданные, такие как code ошибка или params которые затем доступны для интерполяции в сообщение об ошибке (подробнее см. Создание ValidationError ); однако до Django 1.7 эти метаданные отбрасывались, когда добавлялись ошибки Form.errors .

Form.errors и django.forms.utils.ErrorList теперь храним экземпляры ValidationError , поэтому эти метаданные можно получить в любое время с помощью нового метода Form.errors.as_data .

Затем ValidationError извлеченные экземпляры могут быть идентифицированы по их code ошибке, что позволяет такие вещи, как переписывание сообщения об ошибке или запись пользовательской логики в представление, когда присутствует данная ошибка. Его также можно использовать для сериализации ошибок в настраиваемом формате, таком как XML.

Новый метод Form.errors.as_json() - удобный метод, который возвращает сообщения об ошибках, а также коды ошибок, сериализованные в JSON. as_json() использует as_data() и дает представление о том, как можно расширить новую систему.

Контейнеры ошибок и обратная совместимость

Глубокие изменения в погрешности различных контейнеров были необходимы для поддержки указанных выше особенностей, а именно Form.errors , Django.forms.utils.ErrorList а внутренние хранилища ValidationError . Эти контейнеры, ранее использовавшиеся для хранения строк ошибок, теперь хранят экземпляры, ValidationError а общедоступные API-интерфейсы были адаптированы, чтобы сделать это максимально прозрачным, но если вы использовали частные API-интерфейсы, некоторые изменения не имеют обратной совместимости; см. подробности о конструкторе ValidationError и внутренней памяти .

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

django.contrib.admin

  • Теперь вы можете реализовать атрибуты site_header , site_title а index_title на AdminSite обычае легко изменить название и текст заголовка администрации сайта. Больше не нужно расширять шаблоны!
  • Кнопки django.contrib.admin теперь используют свойство CSS border-radius для закругленных углов, а не фоновые изображения GIF.
  • Некоторые шаблоны интерфейса администратора теперь есть app-<app_name> и классы model-<model_name> в их теге <body> возможности настройки CSS с помощью приложения или по шаблону.
  • Ячейки в списке объектов редактирования интерфейса администратора теперь имеют класс field-<field_name> в коде HTML, позволяющий стилистические настройки.
  • Благодаря новому методу поля поиска в интерфейсе администрирования теперь можно настраивать по запросу django.contrib.admin.ModelAdmin.get_search_fields() .
  • Этот метод ModelAdmin.get_fields() можно расширить, чтобы настроить значение ModelAdmin.fields .
  • В дополнение к admin.site.register существующему синтаксису вы можете использовать новый декоратор register() для регистрации ModelAdmin .
  • Можно указать отключение ссылок в сетке страницы списка объектов для редактирования.ModelAdmin.list_display_links = None
  • Теперь вы можете указать, ModelAdmin.view_on_site будет ли отображаться ссылка «Просмотр на сайте».
  • Вы можете указать порядок убывания значения ModelAdmin.list_display , поставив перед значением admin_order_field дефис.
  • Метод ModelAdmin.get_changeform_initial_data() может быть расширен для определения пользовательского поведения для настройки исходных данных формы редактирования.

django.contrib.auth

  • Все, что **kwargs передается email_user() , передается в базовом вызове send_mail() .
  • Декоратор permission_required() может так же легко получить список разрешений, как и одно разрешение.
  • Вы можете расширить новый метод, AuthenticationForm.confirm_login_allowed() чтобы упростить настройку политики входа в систему.
  • django.contrib.auth.views.password_reset() принимает необязательный html_email_template_name параметр, используемый для отправки составного HTML-письма для сброса пароля.
  • AbstractBaseUser.get_session_auth_hash() Добавили метод , и если ваши AUTH_USER_MODEL наследуется от AbstractBaseUser , изменения пароля пользователя теперь аннулирует старые сессии , если django.contrib.auth.middleware.SessionAuthenticationMiddleware включен. Дополнительные сведения см. В разделе « Аннулирование сеанса при смене пароля» .

django.contrib.formtools

  • Призывы WizardView.done() теперь включать в себя, form_dict чтобы упростить доступ к формам по имени их шага.

django.contrib.gis

  • Версия библиотеки OpenLayers по умолчанию, включенная в компоненты, была обновлена ​​с 2.11 до 2.13.
  • Подготовленные геометрии теперь поддерживают предикаты crosses , disjoint , overlaps , touches и within , если GEOS 3.3 или более позднюю версию.

django.contrib.messages

django.contrib.redirects

django.contrib.sessions

  • Теперь "django.contrib.sessions.backends.cached_db" серверная часть сеанса уважает SESSION_CACHE_ALIAS . В предыдущих версиях всегда использовался default кеш.

django.contrib.sitemaps

  • L » теперь используется для определения заголовка в ответе. Это позволяет обрабатывать условные запросы для карт сайта, которые определяют .infrastructure de plan du site lastmod Last-Modified ConditionalGetMiddleware GET lastmod

django.contrib.sites

django.contrib.staticfiles

  • В классах хранения статических файлов могут быть подразделено заменить разрешения статических файлов и каталоги получать собранные путем корректировки параметров file_permissions_mode и directory_permissions_mode . См. collectstatic Пример использования.

  • CachedStaticFilesStorage Бэкенд получает класс родственного под названием , ManifestStaticFilesStorage которое не использует систему кэширования на всех , но вместо того, чтобы файл в формате JSON с именем staticfiles.json для сохранения соответствия между именем исходного файла (например css/styles.css ) и именем файла Хешированного (например css/styles.55e7cbb9ba48.css ). staticfiles.json Файл создается при выполнении collectstatic команды управления и должна быть менее дорогой альтернативой для удаленных хранилищ , таких как Amazon S3.

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

  • findstatic теперь принимает уровень детализации 2, что означает, что он будет отображать относительные пути к каталогам, которые он искал. См. findstatic Пример вывода.

django.contrib.syndication

  • Элемент updated фида синдикации Atom1Feed теперь использует updateddate вместо pubdate , что позволяет published включить элемент в фид (который основан на pubdate ).

Кэш

  • Доступ к настроенным кешам CACHES теперь доступен через django.core.cache.caches . Этот dict-подобный объект предоставляет отдельный экземпляр для каждого потока. Он заменяет то, django.core.cache.get_cache() что теперь устарело.
  • Если вы создали экземпляр механизма кэширования напрямую, имейте в виду, что он больше не является потокобезопасным, поскольку django.core.cache.caches теперь порождает разные экземпляры для каждого потока.
  • Установка аргумента TIMEOUT в настройках , CACHES чтобы будет None установить ключи кэша «не истекающий» по умолчанию. Раньше можно было переключиться только на метод кэширования.timeout = None set()

Подделка межсайтовых запросов

  • Настройка CSRF_COOKIE_AGE упрощает использование файлов cookie сеанса CSRF.

Электронная почта

  • send_mail() теперь принимает html_message параметр для отправки электронного письма, состоящего из нескольких частей text / plain и text / html .
  • Теперь SMTP EmailBackend принимает timeout параметр.

Файловое хранилище

  • Блокировка файлов в Windows ранее зависела от пакета PyWin32; если бы он не был установлен, блокировка файла завершилась бы ошибкой. Эта зависимость была удалена, и теперь блокировка файлов встроена как в Windows, так и в Unix.

Загрузка файлов

  • Новый атрибут UploadedFile.content_type_extra содержит дополнительные параметры, передаваемые в заголовок content-type во время загрузки файла.
  • Новый параметр FILE_UPLOAD_DIRECTORY_PERMISSIONS управляет разрешениями файловой системы для каталогов, созданных во время загрузки файлов, так же, как FILE_UPLOAD_PERMISSIONS и для файлов.
  • Атрибут FileField.upload_to теперь необязательный. Если он опущен, установлен в значение None или пустая строка, подкаталог не будет использоваться для хранения загруженных файлов.
  • Загруженные файлы теперь явно закрываются до того, как ответ будет доставлен клиенту. Частично загруженные файлы также закрываются, если они указаны file в диспетчере загрузки.
  • Storage.get_available_name() Теперь добавьте подчеркивание плюс буквенно-цифровую строку из 7 случайных символов (например "_x3a1gho" ), а не перебирайте подчеркивание, за которым следует число (например "_1" , "_2" и т. Д.), Чтобы предотвратить DoS-атаку. служба. Это изменение также было внесено в версии безопасности 1.6.6, 1.5.9 и 1.4.14.

Формы

  • Ключевые слова <label> и <input> оказываемые RadioSelect и CheckboxSelectMultiple когда Перебор переключателей или флажков в настоящее время включают for и атрибуты id , соответственно. Каждый переключатель или флажок включает атрибут, который id_for_label создает идентификатор элемента.
  • Теги , <textarea> предоставляемые в Textarea настоящее время включают в себя атрибут , maxlength если поле шаблона TextField имеет один max_length .
  • Field.choices теперь позволяет настраивать тег «пустой выбор» путем включения кортежа с пустой строкой или None для ключа и настраиваемого тега в качестве значения. Пустая опция по умолчанию "----------" в этом случае будет опущена.
  • MultiValueField разрешить необязательные подполя, задав для аргумента require_all_fields значение False . Атрибут required для каждого отдельного поля будет соблюдаться, и новая ошибка проверки incomplete будет вызвана, когда обязательное поле будет пустым.
  • Метод clean() формы больше не нужно возвращать self.cleaned_data . Если он вернет измененный словарь, он будет использован.
  • После временной регрессии в Django 1.6, теперь снова можно гарантировать , что метод coerce по TypedChoiceField возвращению произвольного значения.
  • SelectDateWidget.months можно использовать для настройки формулировки месяцев, отображаемых в виджете выбора.
  • Параметры min_num и validate_min были добавлены, чтобы formset_factory() обеспечить проверку минимального количества отправленных форм.
  • Метаклассы, используемые Form и ModelForm были переработаны для обработки сценариев множественного наследования. Предыдущее ограничение , которое одновременно предотвратить наследование двух Form и ModelForm был удален, пока ModelForm первым в MRO.
  • Теперь можно удалить поле из поля Form во время подклассификации, задав для него имя None .
  • Теперь можно настроить сообщения об ошибках для ограничения unique , unique_for_date и unique_together из ModelForm . Чтобы поддержать unique_together или что-то еще NON_FIELD_ERROR , ModelForm теперь посмотрите на ключ NON_FIELD_ERROR в словаре внутреннего error_messages класса . Для получения более подробной информации см. Соображения по модели error_messages .Meta ModelForm

Интернационализация

  • Атрибут django.middleware.locale.LocaleMiddleware.response_redirect_class позволяет настраивать перенаправления, создаваемые промежуточным программным обеспечением.
  • LocaleMiddleware Теперь хранит язык , выбранный пользователем с помощью ключа сеанса _language . Он должен быть доступен только с помощью константы LANGUAGE_SESSION_KEY . Раньше он хранился с ключом, django_language а константа LANGUAGE_SESSION_KEY не существовала, но ключи, зарезервированные Django, должны начинаться с подчеркивания. Для обратной совместимости django_language всегда читается в 1.7. Сеансы будут перенесены на новый ключ по мере их написания.
  • Тег blocktrans теперь поддерживает параметр trimmed . Этот параметр удалит символы новой строки в начале и конце содержимого тега {%blocktrans%} , заменит пробелы в начале и конце строки и объединит все строки в одну с помощью пробела. разделить их. Это очень полезно для отступа содержимого тега без наличия символов отступа в соответствующей записи PO-файла, что упрощает процесс перевода.{% blocktrans%}
  • При запуске makemessages из корневого каталога проекта все извлеченные строки будут автоматически отправляться в приложение или файл сообщения проекта. Дополнительные сведения см. В разделе « Регионализация: создание языковых файлов» .
  • Теперь команда makemessages всегда добавляет к команде флаг --previous командной msgmerge строки, сохраняя строки, уже переведенные в файлы po для нечетких строк.
  • Следующие параметры были введены для решения варианты языка печенья: LANGUAGE_COOKIE_AGE , LANGUAGE_COOKIE_DOMAIN и LANGUAGE_COOKIE_PATH .
  • Добавлена регионализация форматов для эсперанто.

Команды администрирования

  • Новая --no-color опция django-admin отключает раскрашивание вывода команд управления.

  • Параметры new и , а также аргументы new и for позволяют использовать естественные первичные ключи при сериализации.dumpdata --natural-foreign dumpdata --natural-primary use_natural_foreign_keys use_natural_primary_keys serializers.serialize()

  • Больше нет необходимости указывать имя таблицы кэша или --database параметр для createcachetable команды. Django берет эту информацию из вашего файла настроек. Если вы настроили несколько кешей или несколько баз данных, будут созданы все таблицы кешей.

  • Команда runserver получила несколько улучшений:

    • В системах Linux, если установлен pyinotify , сервер разработки немедленно перезагружается при изменении файла. Раньше он каждую секунду опрашивал файловую систему на предмет изменений. Это вызвало небольшую задержку перед подзарядкой и уменьшило время автономной работы портативных компьютеров.
    • Кроме того, сервер разработки автоматически перезагружается при обновлении файла перевода, то есть после выполнения compilemessages .
    • В консоли регистрируются все HTTP-запросы, включая запросы статических файлов или те favicon.ico , которые обычно отфильтровывались.
  • Команды управления теперь могут создавать цветной синтаксис вывода в Windows, если сторонний инструмент ANSICON установлен и запущен.

  • Команда collectstatic теперь поддерживает параметр символической ссылки в Windows NT 6 (Windows Vista и новее).

  • Исходные данные SQL теперь работают лучше, если установлена библиотека sqlparse Python.

    Обратите внимание, что эта практика не рекомендуется в пользу операции RunSQL миграции, которая выигрывает от улучшенного поведения.

Модели

  • Метод QuerySet.update_or_create() был добавлен.
  • Новая опция Meta шаблона default_permissions позволяет вам настроить (или отключить) создание разрешений на добавление, редактирование и удаление по умолчанию.
  • В OneToOneField явные из них для Multi-Table Inheritance теперь обнаружены в абстрактных классах.
  • Теперь можно избежать создания обратной связи для OneToOneField , задав для нее related_name значение '+' или завершив его на '+' .
  • Их поддерживает оператор мощности ( ).expressions F **
  • Методы remove() и clean() связанные обработчики, созданные ForeignKey и GenericForeignKey теперь принимают аргумент ключевого слова, bulk чтобы контролировать, используются ли массовые операции (т.е. использование QuerySet.update() ). По умолчанию True .
  • Теперь можно использовать None значение запроса для поиска iexact .
  • Теперь можно передать вызываемый объект в качестве значения атрибута limit_choices_to при определении одного ForeignKey или одного ManyToManyField .
  • Обращение к результату only() и defer() по результату QuerySet.values() теперь вызывает ошибку (до этого это приводило либо к ошибке базы данных, либо к неверным данным).
  • Вы можете использовать один список для index_together (а не список списков) при указании одного набора полей.
  • Промежуточные пользовательские модели, имеющие более одного внешнего ключа для одной из моделей, участвующих в множественном отношении, теперь разрешены при условии, что вы явно укажете, какие внешние ключи следует использовать при настройке нового аргумента ManyToManyField.through_fields .
  • Присвоение экземпляра шаблона нереляционному полю теперь вызовет ошибку. Раньше это работало, если поле, играющее роль первичного ключа, принимало целые числа в качестве входных данных.
  • Целочисленные поля теперь проверяются максимальными и минимальными значениями, специфичными для механизма базы данных, в соответствии с их internal_type . Ранее проверка поля шаблона не препятствовала сохранению значений, выходящих за пределы диапазона значений, относящихся к типу столбца; затем приводит к ошибке целостности.
  • Теперь его можно использовать order_by() явно с полем отношения _id , используя имя его атрибута.

Сигналы

  • К enter сигналу добавлен аргумент setting_changed .
  • Сигналы модели теперь могут быть связаны с использованием str формата in, 'app_label.ModelName' как и связанные поля, для ленивых ссылок на их эмиттеры.

Шаблоны

  • Теперь метод Context.push() возвращает обработчик контекста, который автоматически вызывает pop() при выходе из объявления with . Кроме того, push() теперь принимает параметры, которые передаются dict конструктору, который используется для создания нового уровня контекста.
  • Новый метод Context.flatten() возвращает стек Context в виде единого плоского словаря.
  • Объекты Context теперь можно сравнивать на предмет равенства (внутренне это используется, Context.flatten() чтобы внутренняя структура каждого стека Context не имела значения, если их плоская версия одинакова).
  • Тег шаблона widthratio теперь принимает параметр "as" для фиксации результата в переменной.
  • Тег шаблона include теперь также принимает все, что имеет метод render() (например, Template ) в качестве аргумента. Как всегда, поиск аргументов в виде строк будет выполняться get_template() .
  • Теперь можно рекурсивно включать шаблоны с помощью include .
  • У объектов шаблона теперь установлен атрибут происхождения, когда он TEMPLATE_DEBUG есть True . Это позволяет проверять источники шаблонов и регистрировать их вне django.template инфраструктуры.
  • Исключения TypeError больше не заглушаются при возникновении во время рендеринга шаблона.
  • Следующие функции теперь принимают dirs параметр, который является переопределенным списком или кортежем TEMPLATE_DIRS :
  • time Фильтр теперь принимает часовой пояс , связанных с спецификаторов размера 'e' , 'O' , 'T' и 'Z' и надежно усваивать часовой пояс-зависимые datetime органы , выполняющие ожидаемый рендеринг.
  • cache Тег теперь будет пытаться использовать кэш под названием «template_fragments» , если она существует и возвращаться к использованию кэша по умолчанию в противном случае. Он также теперь принимает необязательный using аргумент ключевого слова для управления используемым кешем.
  • Новый truncatechars_html фильтр обрезает строку до длины, не превышающей указанное количество символов, с учетом HTML.

Запросы и ответы

  • Новый HttpRequest.scheme атрибут определяет схему запроса ( http или https обычно).
  • Ярлык redirect() теперь поддерживает относительные URL-адреса.
  • Новый JsonResponse подкласс HttpResponse помогает легко создавать ответы в формате JSON.

Тесты

  • DiscoverRunner имеет два новых атрибута test_suite и test_runner , которые упрощают переопределение способа сбора и запуска тестов.
  • fetch_redirect_response Аргумент был добавлен в assertRedirects() . Поскольку тестовый клиент не может получать внешние URL-адреса, это позволяет использовать assertRedirects перенаправления, которые не являются частью вашего приложения Django.
  • Правильная обработка схемы при сравнении в assertRedirects() .
  • secure Аргумент был добавлен ко всем методам запроса о Client . Если True , то запрос будет сделан через HTTPS.
  • assertNumQueries() теперь выводит список выполненных запросов, если утверждение не выполняется.
  • WSGIRequest Экземпляр генерируется тест - обработчик теперь прикреплен к django.test.Response.wsgi_request атрибуту.
  • Настройки базы данных для тестирования были собраны в словарь с именем TEST .

Утилиты

  • Повышенная точность strip_tags() (но все еще не может гарантировать безопасный вывод HTML, как указано в документации).

Валидаторы

  • RegexValidator теперь принимает необязательные flags и логические inverse_match аргументы. inverse_match Атрибут определяет , будет ли ValidationError должен быть поднят , когда регулярное выражение соответствует ( True ) или не соответствует ( False по умолчанию) предоставленный value . flags Атрибут устанавливает флаги , используемые при составлении регулярных выражений строки.
  • URLValidator теперь принимает необязательный schemes аргумент, который позволяет настраивать принятые схемы URI (вместо значений по умолчанию http(s) и ftp(s) ).
  • validate_email() теперь принимает адреса с литералами IPv6, например [email protected][2001:db8::1] , как указано в RFC 5321.

Backwards несовместимые изменения в 1.7

Предупреждение

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

allow_syncdb / allow_migrate

Хотя Django по-прежнему будет рассматривать allow_syncdb методы, даже если они должны быть переименованы в allow_migrate , существует небольшая разница в том, какие модели передаются этим методам.

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

initial_data

Приложения с миграциями не будут загружать initial_data фикстуры после завершения миграции. Приложения без миграции будут продолжать загружать эти фикстуры на этапе, migrate имитирующем старое syncdb поведение, но любые новые приложения не будут иметь этой поддержки.

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

Кроме того, как и остальной старый syncdb код Django , initial_data был запущен по пути устаревания и будет удален в Django 1.9.

deconstruct () и сериализуемость

Django теперь требует, чтобы все классы Field и все их аргументы конструктора были сериализуемыми. Если вы каким-либо образом измените подпись конструктора в своем настраиваемом поле, вам потребуется реализовать метод deconstruct (); мы расширили документацию по настраиваемым полям инструкциями по реализации этого метода .

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

App загрузка изменений

Последовательность запуска

Django 1.7 загружает конфигурации и модели приложения сразу после запуска. Хотя такое поведение более прямолинейно и считается более устойчивым, нельзя исключать регрессии. См. Раздел « Поиск и устранение неисправностей» для решения некоторых проблем, с которыми вы можете столкнуться.

Автономные скрипты

Если вы используете Django в простом скрипте Python, а не в команде управления, и полагаетесь на DJANGO_SETTINGS_MODULE переменной среды, теперь вы должны явно инициализировать Django в начале вашего скрипта с помощью:

>>> import django
>>> django.setup()

В противном случае вы попадете в AppRegistryNotReady исключение.

Скрипты WSGI

До Django 1.3 рекомендуемый способ создания приложения WSGI был:

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

В Django 1.4 была улучшена поддержка WSGI, а API изменен на:

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

Если вы все еще используете первый стиль в своем сценарии WSGI, вам необходимо перейти на второй, иначе вы столкнетесь с AppRegistryNotReady исключением.

Согласованность реестра приложений

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

Если у вас есть два приложения с одинаковым ярлыком, вы должны создать AppConfig для одного из них и переопределить его label там. Затем вы должны скорректировать свой код везде, где он ссылается на это приложение или его модели со старой меткой.

Больше невозможно импортировать одну и ту же модель дважды по разным путям. Начиная с Django 1.6, это может произойти, только если вы вручную помещаете каталог и подкаталог вPYTHONPATH , Инструкции по миграции см. В разделе о новом макете проекта в примечаниях к выпуску 1.4 .

Вы должны убедиться:

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

Django будет применять эти требования с версии 1.9 после периода прекращения поддержки.

Создание подкласса AppCommand

Подклассы AppCommand теперь должны реализовывать handle_app_config() метод вместо handle_app() . Этот метод получает AppConfig экземпляр вместо модуля моделей.

Изучение приложений

Поскольку INSTALLED_APPS теперь в дополнение к модулям приложения поддерживаются классы конфигурации приложения, вам следует просмотреть код, который обращается к этому параметру напрямую, и django.apps.apps вместо этого использовать реестр приложений ( ).

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

  • get_model возникает LookupError вместо возврата, None если модель не найдена.
  • only_installed Аргумент get_model и get_models больше не существует, и не делает seed_cache аргумент get_model .

Команды управления и порядок INSTALLED_APPS

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

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

ValidationError конструктор и внутреннее хранилище

Поведение ValidationError конструктора изменилось, когда он получил контейнер ошибок в качестве аргумента (например, a list или an ErrorList ):

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

Это означает, что если вы обращаетесь к ValidationError внутренним хранилищам, например error_list : error_dict ; или возвращаемое значение update_error_dict() you может найти экземпляры того места, ValidationError где вы раньше находили строки.

Кроме того, если вы непосредственно закрепленные возвращаемое значение update_error_dict() для Form._errors вас может непреднамеренно добавить list случаев , когда ErrorList ожидаются экземпляры. Это проблема, потому что, в отличие от простого list , объект ErrorList знает, как обрабатывать экземпляры ValidationError .

Большинство случаев использования, которые требуют использования этих частных API, теперь покрываются новым Form.add_error() методом:

# Old pattern:
try:
    # ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# New pattern:
try:
    # ...
except ValidationError as e:
    self.add_error(None, e)

Если вам нужна совместимость как с Django <= 1.6, так и с 1.7, вы не можете использовать ее, Form.add_error() поскольку она не была доступна до Django 1.7, но вы можете использовать следующий обходной путь для преобразования любого list в ErrorList :

try:
    # ...
except ValidationError as e:
    self._errors = e.update_error_dict(self._errors)

# Additional code to ensure ``ErrorDict`` is exclusively
# composed of ``ErrorList`` instances.
for field, error_list in self._errors.items():
    if not isinstance(error_list, self.error_class):
        self._errors[field] = self.error_class(error_list)

Поведение в LocMemCache отношении ошибок рассола

В предыдущих версиях Django существовала несогласованность в том, как ошибки рассоления обрабатываются различными серверными модулями кеширования. django.core.cache.backends.locmem.LocMemCache используется для автоматического отказа при возникновении такой ошибки, что несовместимо с другими серверными модулями и приводит к ошибкам, связанным с кешем. Это было исправлено в Django 1.7, подробнее см. # 21200 .

Ключи кеша теперь генерируются из абсолютного URL запроса

Предыдущие версии Django генерировали ключи кеша, используя путь запроса и строку запроса, но не схему или хост. Если приложение Django обслуживает несколько поддоменов или доменов, ключи кеша могут конфликтовать. В Django 1.7 ключи кеша различаются абсолютным URL-адресом запроса, включая схему, хост, путь и строку запроса. Например, URL - часть ключа кэша теперь генерируется из , https://www.example.com/path/to/?key=val а не /path/to/?key=val . Ключи кеша, сгенерированные Django 1.7, будут отличаться от ключей, сгенерированных более старыми версиями Django. После обновления до Django 1.7 первый запрос к любому ранее кэшированному URL-адресу будет промахом в кеше.

Переход None на Manager.db_manager()

В предыдущих версиях Django можно было использовать db_manager(using=None) экземпляр диспетчера моделей для получения экземпляра диспетчера с использованием поведения маршрутизации по умолчанию, отменяя любую заданную вручную маршрутизацию базы данных. В Django 1.7 значение, None переданное в db_manager, создаст маршрутизатор, который сохраняет любую назначенную вручную маршрутизацию базы данных - менеджер не будет сброшен. Это было необходимо для устранения несоответствия в способе каскадной передачи информации о маршрутизации через соединения. См. # 13724 для более подробной информации.

pytz может потребоваться

Если ваш проект обрабатывает даты до 1970 года или после 2037 года, а Django вызывает их ValueError при обнаружении, вам придется установить pytz . Эта проблема может возникнуть при использовании форматов даты Django, связанных с часовыми поясами, или django.contrib.syndication .

Стратегия перенаправления входа администратора

Исторически сложилось так, что сайт администратора Django передавал запрос от неавторизованного или не прошедшего проверку подлинности пользователя непосредственно в представление входа в систему без перенаправления HTTP. В Django 1.7 это поведение изменилось, чтобы соответствовать более традиционному рабочему процессу, при котором любой неавторизованный запрос на страницу администратора будет перенаправлен (с помощью кода состояния HTTP 302) на страницу входа с next параметром, установленным на путь ссылки. Пользователь будет перенаправлен туда после успешного входа в систему.

Также обратите внимание, что форма входа в систему администратора была обновлена, чтобы не содержать this_is_the_login_form поля (теперь не используется), а ValidationError код был установлен на более обычный invalid_login ключ.

select_for_update() требуется транзакция

Исторически запросы с использованием select_for_update() могли выполняться в режиме автоматической фиксации вне транзакции. До Django 1.6 автоматический режим транзакций Django позволял блокировать элементы до следующей операции записи. Django 1.6 представляет автоматическую фиксацию на уровне базы данных; с тех пор работа в таком контексте сводит на нет эффект select_for_update() . Таким образом, теперь предполагается, что это ошибка, и возникает исключение.

Это изменение было внесено, потому что такие ошибки могут быть вызваны включением приложения, которое ожидает глобальные транзакции (например, с ATOMIC_REQUESTS установленным значением True ), или старым поведением автоматической фиксации Django, в проект, который работает без них; и, кроме того, такие ошибки могут проявляться как ошибки повреждения данных. Это также было сделано в Django 1.6.3.

Это изменение может вызвать сбои теста, если вы используете select_for_update() в тестовом классе, который является подклассом TransactionTestCase вместо TestCase .

Промежуточное ПО Contrib удалено из дефолта MIDDLEWARE_CLASSES

Приложение заряжание рефакторинг осуждается с использованием моделей из приложений , которые не являются частью INSTALLED_APPS установки. Это выявило несовместимость между значениями по умолчанию INSTALLED_APPS и MIDDLEWARE_CLASSES глобальными значениями по умолчанию ( django.conf.global_settings ). Довести диссертацию в настройках синхронизации и предотвратить предупреждения устаревания профилактики Когда делать вещи , как тестирование повторно используемых приложений с минимальными настройками, SessionMiddleware , AuthenticationMiddleware и MessageMiddleware были удалены из значения по умолчанию. Эти классы по-прежнему будут включены в настройки по умолчанию, созданные с помощью startproject . Это изменение не повлияет на большинство проектов, но если вы ранее не заявляли MIDDLEWARE_CLASSES в настройках вашего проекта и полагаясь на глобальное значение по умолчанию, вы должны убедиться, что новые значения по умолчанию соответствуют потребностям вашего проекта. Вы также должны проверить любой код, который обращается django.conf.global_settings.MIDDLEWARE_CLASSES напрямую.

Разное

  • Теперь django.core.files.uploadhandler.FileUploadHandler.new_file() методу передается дополнительный content_type_extra параметр. Если у вас есть кастом, FileUploadHandler который реализует new_file() , убедитесь, что он принимает этот новый параметр.

  • ModelFormSet s больше не удаляют экземпляры при save(commit=False) вызове. См. can_delete Инструкции по удалению объектов из удаленных форм вручную.

  • Загрузка пустых приборов приводит к появлению сообщения, RuntimeWarning а не к повышению CommandError .

  • django.contrib.staticfiles.views.serve() теперь будет вызывать Http404 исключение, а не ImproperlyConfigured когда DEBUG есть False . Это изменение устраняет необходимость условного добавления представления в корневой URLconf, что, в свою очередь, делает безопасным обратное изменение по имени. Он также исключает возможность для посетителей генерировать ложные ошибки HTTP 500, запрашивая статические файлы, которые не существуют или еще не были собраны.

  • Теперь django.db.models.Model.__eq__() метод определен таким образом, что экземпляры прокси-модели и ее базовой модели считаются равными при совпадении первичных ключей. Ранее только экземпляры одного и того же класса считались равными при совпадении первичного ключа.

  • django.db.models.Model.__eq__() Метод изменился таким образом, что два Model экземпляра без значений первичного ключа не будет считаться равными (если они не являются таким же экземпляром).

  • Теперь django.db.models.Model.__hash__() метод будет повышаться TypeError при вызове экземпляра без значения первичного ключа. Это сделано, чтобы избежать изменяемых __hash__ значений в контейнерах.

  • AutoField столбцы в базах данных SQLite теперь будут создаваться с использованием AUTOINCREMENT опции, которая гарантирует монотонное приращение. Это приведет к изменению поведения нумерации первичных ключей в SQLite, которое станет согласованным с большинством других баз данных SQL. Это будет применяться только к вновь созданным таблицам. Если у вас есть база данных, созданная с помощью более старой версии Django, вам нужно будет перенести ее, чтобы воспользоваться этой функцией. Например, вы можете сделать следующее:

    1. Используйте dumpdata для сохранения ваших данных.
    2. Переименуйте существующий файл базы данных (сохраните его как резервную копию).
    3. Запустите, migrate чтобы создать обновленную схему.
    4. Используйте loaddata для импорта приборов, которые вы экспортировали в (1).
  • django.contrib.auth.models.AbstractUser больше не определяет get_absolute_url() метод. Возвращено старое определение, которое было произвольным, поскольку приложения могут определять или не определять такой URL-адрес в . Определите метод для вашего собственного пользовательского объекта или используйте, если вам нужен URL-адрес для вашего пользователя."/users/%s/" % urlquote(self.username) urlpatterns get_absolute_url() ABSOLUTE_URL_OVERRIDES

  • Функциональность django.test.LiveServerTestCase класса по обслуживанию статических ресурсов была упрощена: теперь он может обслуживать только уже присутствующий контент STATIC_ROOT при запуске тестов. Способность прозрачно обслуживать все статические ресурсы (аналогично тому, что есть во время разработки) была перемещена в новый класс, который живет в приложении (тот, который поддерживает функцию Actually such) . Другими словами, сам по себе менее мощный, но в то же время в нем меньше магии.DEBUG = True staticfiles django.contrib.staticfiles.testing.StaticLiveServerTestCase LiveServerTestCase

    Обоснованием этого является устранение зависимости кода, не относящегося к Contrib, от приложений contrib.

  • Старый синтаксис URI кэша (например "locmem://" ) больше не поддерживается. Он по-прежнему работал, хотя не был документирован и официально не поддерживался. Если вы все еще используете его, обновите CACHES синтаксис до текущего .

  • Порядок Form полей по умолчанию в случае наследования изменен, чтобы соответствовать обычному Python MRO. Поля теперь обнаруживаются путем повторения MRO в обратном порядке, причем последним идет самый верхний класс. Это повлияет на вас только в том случае, если вы полагались на порядок полей по умолчанию, имея поля, определенные как для текущего класса, так и для родительского Form .

  • required Аргумент SelectDateWidget был удален. Этот виджет теперь учитывает is_required атрибут поля формы, как и другие виджеты.

  • Widget.is_hidden теперь является свойством только для чтения, значение которого определяется путем самоанализа наличия .input_type == 'hidden'

  • select_related() now связывается так же, как и другие подобные вызовы, например prefetch_related . То есть эквивалентно . Ранее последнее было бы эквивалентом .select_related('foo', 'bar') select_related('foo').select_related('bar') select_related('bar')

  • GeoDjango прекращает поддержку GEOS <3.1.

  • init_connection_state Метод движков баз данных в настоящее время выполняется в режиме автоматической фиксации (если не установлен AUTOCOMMIT в False ). Если вы поддерживаете собственный сервер базы данных, вам следует проверить этот метод.

  • django.db.backends.BaseDatabaseFeatures.allows_primary_key_0 Атрибут был переименован , allows_auto_pk_0 чтобы лучше описать его. Это True для всех баз данных, включенных в Django, за исключением MySQL, который разрешает первичные ключи со значением 0. Он запрещает автоинкремент только первичных ключей со значением 0.

  • Затенение полей модели, определенных в родительской модели, запрещено, поскольку это создает неоднозначность в ожидаемом поведении модели. Кроме того, конфликтующие поля в иерархии наследования модели приводят к ошибке проверки системы. Например, если вы используете множественное наследование, вам необходимо определить настраиваемые поля первичного ключа в родительских моделях, иначе id поля по умолчанию будут конфликтовать. Подробнее см. Множественное наследование .

  • django.utils.translation.parse_accept_lang_header() теперь возвращает языковые стандарты в нижнем регистре вместо того, как это было предусмотрено. Поскольку языковые стандарты следует обрабатывать без учета регистра, это позволяет нам ускорить определение языковых стандартов.

  • django.utils.translation.get_language_from_path() и django.utils.translation.trans_real.get_supported_language_variant() теперь уже нет supported аргументов.

  • shortcut Вид в django.contrib.contenttypes.views теперь поддерживает протокол-относительный URL - адресов (например //example.com ).

  • GenericRelation теперь поддерживает необязательный related_query_name аргумент. Настройка related_query_name добавляет отношение связанного объекта обратно к типу контента для фильтрации, упорядочивания и других операций запроса.

  • При запуске тестов на PostgreSQL USER потребуется доступ для чтения к встроенной postgres базе данных. Это заменяет предыдущее поведение при подключении к фактической не тестовой базе данных.

  • В рамках проверки системы базы , поля, модель и менеджеры модели все реализовать check() метод , который зарегистрирован с контрольной рамкой. Если у вас есть существующий метод, вызываемый check() для одного из этих объектов, вам необходимо переименовать его.

  • Как отмечалось выше в разделе «Кэш» раздела «Незначительные функции», определение TIMEOUT аргумента CACHES параметра as None установит ключи кеша как «бессрочные». Раньше с бэкэндом memcache a TIMEOUT of 0 устанавливал ключи с неограниченным сроком действия, но это несовместимо с поведением set-and-expire (то есть без кеширования) . Если вам нужны ключи с неограниченным сроком действия, обновите свои настройки, чтобы использовать их вместо того, чтобы последний теперь также обозначает в настройках срок действия и истечения срока действия.set("key", "value", timeout=0) None 0

  • Эти sql* команды управления в настоящее время соблюдать allow_migrate() метод DATABASE_ROUTERS . Если у вас есть модели, синхронизированные с базами данных, отличными от стандартных, используйте --database флаг, чтобы получить SQL для этих моделей (раньше они всегда включались в вывод).

  • Декодирование строки запроса из URL-адресов теперь возвращается к кодировке ISO-8859-1, когда ввод не является допустимым UTF-8.

  • При добавлении django.contrib.auth.middleware.SessionAuthenticationMiddleware к шаблону проекта по умолчанию (только до версии 1.7.2) база данных должна быть создана перед доступом к странице с использованием runserver .

  • Добавление schemes аргумента к URLValidator будет отображаться как изменение с обратной несовместимостью, если вы ранее использовали настраиваемое регулярное выражение для проверки схем. Любая схема, не указанная в списке, не schemes пройдет проверку, даже если регулярное выражение соответствует заданному URL.

Функции, устаревшие в версии 1.7

django.core.cache.get_cache

django.core.cache.get_cache был заменен на django.core.cache.caches .

django.utils.dictconfig / django.utils.importlib

django.utils.dictconfig и django.utils.importlib были копиями соответственно logging.config и importlib предоставлялись для версий Python до 2.7. Они устарели.

django.utils.module_loading.import_by_path

Текущая django.utils.module_loading.import_by_path функция перехватывает AttributeError , ImportError и ValueError исключения, и повторно поднимает ImproperlyConfigured . Такое маскирование исключений излишне усложняет диагностику проблем циклического импорта, поскольку создает впечатление, что проблема исходит изнутри Django. Он устарел и заменен на import_string() .

django.utils.tzinfo

django.utils.tzinfo предоставил два tzinfo подкласса LocalTimezone и FixedOffset . Они устарели в пользу более правильных альтернатив, предоставляемых django.utils.timezone , django.utils.timezone.get_default_timezone() и django.utils.timezone.get_fixed_timezone() .

django.utils.unittest

django.utils.unittest предоставил единый доступ к unittest2 библиотеке на всех версиях Python. Поскольку он unittest2 стал unittest модулем стандартной библиотеки в Python 2.7, а Django 1.7 отказался от поддержки более старых версий Python, этот модуль больше не полезен. Он устарел. unittest Вместо этого используйте .

django.utils.datastructures.SortedDict

Поскольку он OrderedDict был добавлен в стандартную библиотеку в Python 2.7, SortedDict больше не требуется и устарел.

Два дополнительных устаревших метода, предоставленные SortedDict ( insert() и value_for_index() ), были удалены. Если вы полагались на эти методы для изменения структур, таких как поля формы, теперь вы должны рассматривать их OrderedDict как неизменяемые объекты и переопределять их для изменения их содержимого.

Например, вы можете захотеть переопределить MyFormClass.base_fields (хотя этот атрибут не считается публичным API), чтобы изменить порядок полей для всех MyFormClass экземпляров; или аналогично, вы можете переопределить self.fields изнутри MyFormClass.__init__() , чтобы изменить поля для определенного экземпляра формы. Например (из самого Django):

PasswordChangeForm.base_fields = OrderedDict(
    (k, PasswordChangeForm.base_fields[k])
    for k in ['old_password', 'new_password1', 'new_password2']
)

Расположение пользовательского SQL для пакета моделей

Раньше, если модели были организованы в виде package ( myapp/models/ ), а не просто myapp/models.py , Django искал исходные данные SQL в myapp/models/sql/ . Эта ошибка была исправлена, поэтому Django будет выполнять поиск myapp/sql/ в соответствии с документацией. После исправления этой проблемы были добавлены миграции, которые не рекомендуют исходные данные SQL. Таким образом, хотя это изменение все еще существует, исключение не имеет значения, поскольку вся функция будет удалена в Django 1.9.

Реорганизация django.contrib.sites

django.contrib.sites обеспечивает ограниченную функциональность, когда его нет INSTALLED_APPS . Рефакторинг загрузки приложения добавляет некоторые ограничения в этой ситуации. Как следствие, два объекта были перемещены, а старые местоположения устарели:

атрибут declared_fieldsets в ModelAdmin

ModelAdmin.declared_fieldsets устарела. Несмотря на то, что он является частным API, он будет устаревшим. Этот атрибут в основном использовался обходными методами, ModelAdmin.get_fieldsets() но это считалось ошибкой и было исправлено.

Реорганизация django.contrib.contenttypes

Поскольку django.contrib.contenttypes.generic определены объекты, связанные как с администратором, так и с моделью, импорт этого модуля может вызвать неожиданные побочные эффекты. Как следствие, его содержимое было разбито на contenttypes подмодули, и django.contrib.contenttypes.generic модуль устарел:

syncdb

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

модули util переименованы в utils

Следующие экземпляры util.py в кодовой базе Django были переименованы utils.py в, чтобы объединить все ссылки на util и utils:

  • django.contrib.admin.util
  • django.contrib.gis.db.backends.util
  • django.db.backends.util
  • django.forms.util

метод get_formsets в ModelAdmin

ModelAdmin.get_formsets устарел в пользу нового get_formsets_with_inlines() , чтобы лучше справиться со случаем выборочного отображения строк на ModelAdmin .

IPAddressField

django.db.models.IPAddressField И django.forms.IPAddressField поля были устаревшими в пользу django.db.models.GenericIPAddressField и django.forms.GenericIPAddressField .

BaseMemcachedCache._get_memcache_timeout метод

BaseMemcachedCache._get_memcache_timeout() Метод был переименован в get_backend_timeout() . Несмотря на то, что это частный API, он будет устаревшим.

Параметры сериализации естественного ключа

В --natural и -n варианты dumpdata устарели. Вместо этого используйте .dumpdata --natural-foreign

Точно так же use_natural_keys аргумент for serializers.serialize() устарел. use_natural_foreign_keys Вместо этого используйте .

Сращивание POST и GET аргументы в WSGIRequest.REQUEST

Уже было настоятельно рекомендовано использовать GET и POST вместо REQUEST , потому что первые более явны. Это свойство REQUEST устарело и будет удалено в Django 1.9.

класс django.utils.datastructures.MergeDict

MergeDict существует в первую очередь для поддержки слияния POST и GET аргументов в REQUEST свойство WSGIRequest . Для объединения словарей используйте dict.update() вместо них. Этот класс MergeDict устарел и будет удален в Django 1.9.

Языковые коды zh-cn , zh-tw и fy-nl

Используемые в настоящее время коды языков для упрощенного китайского zh-cn , традиционный китайский zh-tw и (западной) Frysian fy-nl устарели и должны быть заменены кодами языков zh-hans , zh-hant и fy соответственно. Если вы используете эти языковые коды, вам следует переименовать каталоги локалей и обновить настройки, чтобы отразить эти изменения. Устаревшие языковые коды будут удалены в Django 1.9.

функция django.utils.functional.memoize

Функция memoize устарела и должна быть заменена functools.lru_cache декоратором (доступен начиная с Python 3.2).

Django предоставляет бэкпорт этого декоратора для более старых версий Python, и он доступен по адресу django.utils.lru_cache.lru_cache . Устаревшая функция будет удалена в Django 1.9.

Гео Sitemap

Google больше не поддерживает формат Geo Sitemaps. Следовательно, поддержка Django для файлов Geo Sitemaps устарела и будет удалена в Django 1.8.

Передача вызываемых аргументов в методы набора запросов

Вызываемые аргументы для наборов запросов были недокументированной функцией, которая была ненадежной. Он устарел и будет удален в Django 1.9.

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

настройка ADMIN_FOR

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

SplitDateTimeWidget с DateTimeField

SplitDateTimeWidget поддержка в DateTimeField осуждается, использование SplitDateTimeWidget с SplitDateTimeField вместо этого.

validate

Команда validate управления устарела в пользу check команды.

django.core.management.BaseCommand

requires_model_validation устарел в пользу нового requires_system_checks флага. Если последний флаг отсутствует, то используется значение первого флага. Определение обоих requires_system_checks и requires_model_validation приводит к ошибке.

Метод check() заменил старый метод validate() .

ModelAdmin валидаторы

ModelAdmin.validator_class И default_validator_class атрибуты являются устаревшими в пользу нового checks_class атрибута.

ModelAdmin.validate() Метод является устаревшим в пользу ModelAdmin.check() .

django.contrib.admin.validation Модуль является устаревшим.

django.db.backends.DatabaseValidation.validate_field

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

Загрузка тегов ssi и url шаблонов из future библиотеки

Django 1.3 введен и синтаксис для прямой совместимости и шаблонных тегов. Этот синтаксис устарел и будет удален в Django 1.9. Вы можете просто удалить теги.{% load ssi from future %} {% load url from future %} ssi url {% load ... from future %}

django.utils.text.javascript_quote

javascript_quote() была недокументированной функцией, присутствующей в django.utils.text . Он использовался внутри javascript_catalog() представления, реализация которого была изменена для использования json.dumps() вместо него. Если вы полагались на эту функцию для обеспечения безопасного вывода из ненадежных строк, вам следует использовать фильтр django.utils.html.escapejs или escapejs шаблон. Если все, что вам нужно, это создать допустимые строки JavaScript, вы можете просто использовать json.dumps() .

fix_ampersands utils метод и шаблонный фильтр

Этот django.utils.html.fix_ampersands метод и fix_ampersands шаблонный фильтр устарели, так как об экранировании амперсандов уже позаботились стандартные функции экранирования HTML Django. Комбинирование этого с fix_ampersands может привести либо к двойному экранированию, либо, если вывод считается безопасным, к риску внедрения XSS-уязвимостей. Наряду с fix_ampersands , django.utils.html.clean_html осуждается, недокументированная функция звонков fix_ampersands . Поскольку это ускоренное устаревания, fix_ampersands и clean_html будут удалены в Django 1.8.

Реорганизация настроек теста базы данных

Все настройки базы данных с TEST_ префиксом устарели и заменены записями в TEST словаре в настройках базы данных. Старые настройки будут поддерживаться до Django 1.9. Для обратной совместимости со старыми версиями Django вы можете определить обе версии настроек, если они совпадают.

Поддержка FastCGI

Поддержка FastCGI с помощью команды runfcgi управления будет удалена в Django 1.9. Разверните свой проект с помощью WSGI.

Перемещенные объекты в contrib.sites

После рефакторинга загрузки приложения django.contrib.sites.models необходимо переместить два объекта, поскольку они должны быть доступны без импорта, django.contrib.sites.models если django.contrib.sites не установлены. Импорт RequestSite из django.contrib.sites.requests и get_current_site() из django.contrib.sites.shortcuts . Старые локации импорта будут работать до Django 1.9.

django.forms.forms.get_declared_fields()

Django no longer uses this functional internally. Even though it’s a private API, it’ll go through the normal deprecation cycle.

Private Query Lookup APIs

Private APIs django.db.models.sql.where.WhereNode.make_atom() and django.db.models.sql.where.Constraint are deprecated in favor of the new custom lookups API.

Features removed in 1.7

These features have reached the end of their deprecation cycle and are removed in Django 1.7. See Features deprecated in 1.5 for details, including how to remove usage of these features.

  • django.utils.simplejson est supprimé.
  • django.utils.itercompat.product est supprimé.
  • INSTALLED_APPS and TEMPLATE_DIRS are no longer corrected from a plain string into a tuple.
  • HttpResponse , SimpleTemplateResponse , TemplateResponse , render_to_response() , index() , and sitemap() no longer take a mimetype argument
  • HttpResponse immediately consumes its content if it’s an iterator.
  • Параметр AUTH_PROFILE_MODULE и get_profile() метод модели User удалены.
  • Порядок управления cleanup удален.
  • Скрипт daily_cleanup.py удален.
  • select_related() больше не имеет depth аргумента ключевого слова.
  • Функции get_warnings_state() / restore_warnings_state() из django.test.utils и save_warnings_state() / restore_warnings_state() django.test. * TestCase удалены.
  • check_for_test_cookie Метод AuthenticationForm удаляется.
  • Версия django.contrib.auth.views.password_reset_confirm() , поддерживающая идентификаторы пользователей в кодировке base36 ( django.contrib.auth.views.password_reset_confirm_uidb36 ), удалена.
  • django.utils.encoding.StrAndUnicode Смесь в удаляется.

Copyright ©2020 All rights reserved