Путь обновления для повторно используемых приложений с миграцией South и django 1.7

Или: могут ли пользователи Django 1.7 использовать Юг?

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

Я смущен тем, как я могу позволить разработчикам использовать мое приложение с Django 1.6 (и югом) и Django 1.7 (новые миграции).

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

Самый близкий к пути обновления, который я мог бы придумать, не использует новую систему миграции, пока я не отброшу поддержку Django <1.7 в моем приложении (поэтому, когда выходит Django 1.8). Но как насчет столкновения именования с командой migrate? И юг, и новая система используют python manage.py migrate для запуска миграции. Итак, пользователи Django 1.7 больше не могут использовать Юг?

3 Solutions collect form web for “Путь обновления для повторно используемых приложений с миграцией South и django 1.7”

Юг 1.0 обеспечивает решение. Он будет выглядеть сначала в папке south_migrations/ и возвращаться к migrations/ . Поэтому в вашем случае сторонних библиотек, которые нуждаются в поддержке более старых и новых Djangos: переместите файлы юга в south_migration/ и создайте новые миграции 1.7 в migrations/ .

  • Примечания к выпуску South 1.0
  • Данго также добавили эту информацию

Юг нельзя использовать с Django 1.7, но это не проблема для конечных пользователей. Они либо используют новый Django, либо более старый Djangos с South 1.0. Не будет юга 2.0, который собирался поддерживать новые миграции в 1.7 стиле. Также ответ @ Ondrej правильный, это было написано до выхода South 1.0, так что правда тогда (всего несколько месяцев назад) состояла только из обходных решений.

Существуют настройки как в Django ( MIGRATION_MODULES ), так и на юге ( SOUTH_MIGRATION_MODULES ), которые позволяют указать модуль с миграциями. Итак, у вас есть 2 варианта:

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

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

Ну, я думаю, вам повезло, если вы перейдете на страницу кикстарта, вы увидите, что его финансирование (£ 17,952) позволяет выполнять 7 000 + задач, включая:

Бэкпорт ключевых функций для новой крупной версии Юга для поддержки тех, кто на Django 1.4 и 1.5

поэтому, если вы хотите, вы можете обновить 1.6 юга, чтобы по крайней мере соответствовать миграции django. Я знаю, что это не совсем то, о чем вы просили, но, похоже, это единственный способ.

  • как восстановить упавшую таблицу с django-south?
  • Обновление с Django 1.6 до 1.9: сбой python manage.py
  • Юг игнорирует изменение значения по умолчанию поля в Python / Django
  • Правило самоанализа Django-South не работает
  • Использование Django South для перехода от конкретного наследования к абстрактному наследованию
  • юг: «Бэкэнд базы данных не принимает 0 в качестве значения для AutoField» (mysql)
  • Поля Django GenericRelation недоступны во время южной миграции
  • Django South - превращение поля null = True в поле null = False
  • Python - лучший язык программирования в мире.