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

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

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

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

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

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

Это изменение не должно повлиять на вас, если вы не пишете собственные подклассы полей; если вы это сделаете, вам может потребоваться переопределить 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класс и все методы , которые были желательные на должны Manager были быть проксированном к 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 (); мы расширили документацию по настраиваемым полям инструкциями по реализации этого метода .

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

Изменения загрузки приложений ¶

>>> 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(), убедитесь, что он принимает этот новый параметр.

• ModelFormSets больше не удаляют экземпляры при 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)urlpatternsget_absolute_url()ABSOLUTE_URL_OVERRIDES

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

  Обоснованием этого является устранение зависимости кода, не относящегося к 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 TIMEOUTof 0устанавливал ключи с неограниченным сроком действия, но это несовместимо с поведением set-and-expire (то есть без кеширования) . Если вам нужны ключи с неограниченным сроком действия, обновите свои настройки, чтобы использовать их вместо того, чтобы последний теперь также указывает в настройках срок действия и истечения срока действия.set("key", "value", timeout=0)None0

• Эти 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 %}ssiurl{% 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_ampersandsutils метод и шаблонный фильтр ¶

Этот 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 больше не использует этот функционал внутри компании. Несмотря на то, что это частный API, он пройдет стандартный цикл устаревания.

API поиска частных запросов ¶

Частные API django.db.models.sql.where.WhereNode.make_atom()и django.db.models.sql.where.Constraintустарели в пользу нового API пользовательского поиска .