Примечания к выпуску 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 команду управления.

Новый объект Prefetch для prefetch_related расширенных операций . ¶

Новый объект Prefetch позволяет настраивать операции предварительной загрузки.

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

Это позволяет выполнять такие операции, как фильтрация предварительно загруженных отношений, вызов select_related() из предварительно загруженной связи или предварительная загрузка одной и той же связи несколько раз с разными наборами запросов. Подробнее prefetch_related() см.

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

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

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

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

До 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 ¶

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

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 загрузка изменений ¶

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

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

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

Команды управления и порядок ¶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 .

remove() и clear() методы связанных менеджеров ¶

В remove() и clear() методах соответствующих менеджеров , созданных ForeignKey , GenericForeignKey и ManyToManyField Пострадавшие от целого ряда вопросов. Некоторые операции выполняли несколько запросов на изменение данных, не заключая их в транзакцию, а некоторые операции не соблюдали фильтрацию по умолчанию, когда она присутствовала (то есть, когда менеджер по умолчанию в связанной модели реализовал заказ get_queryset() ).

При исправлении проблем были внесены некоторые обратно несовместимые изменения:

• Реализация по умолчанию remove() для ForeignKey связанных менеджеров изменилась с серии Model.save() вызовов на один QuerySet.update() вызов. Средства изменения , которые pre_save и post_save сигналы не посланные больше. Вы можете использовать bulk=False аргумент ключевого слова, чтобы вернуться к предыдущему поведению.
• remove() И clear() методы для GenericForeignKey родственных менеджеров в настоящее время выполняют массовое удаление. Этот Model.delete() метод больше не вызывается для каждого экземпляра. Вы можете использовать bulk=False аргумент ключевого слова, чтобы вернуться к предыдущему поведению.
• В remove() и clear() методах ManyToManyField смежных менеджеров выполняют вложенные запросы при фильтрации участвующие, которые могут или не могут быть проблемой в зависимости от вашей базы данных и самых данных. См. Это примечание для получения более подробной информации.

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

Исторически сложилось так, что сайт администратора 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.

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 . Рефакторинг загрузки приложения добавляет некоторые ограничения в этой ситуации. Как следствие, два объекта были перемещены, а старые местоположения устарели:

• RequestSite сейчас живет в django.contrib.sites.requests .
• get_current_site() сейчас живет в django.contrib.sites.shortcuts .

атрибут declared_fieldsets в ModelAdmin ¶

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

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

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

• GenericForeignKey а GenericRelation теперь живем в fields .
• BaseGenericInlineFormSet а generic_inlineformset_factory() теперь живем в forms .
• GenericInlineModelAdmin , GenericStackedInline а GenericTabularInline теперь живем в admin .

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.