В настоящее время с помощью Django “Эволюция”, “Юг” лучше и стоящий переключения?

Я только начал использовать Юг, и я на 100% продан ему. Это также один из немногих, который все еще находится в стадии активной разработки.

South должен быть в состоянии должным образом решить проблемы, которые вы описали выше. Для каждого изменения в базе данных создается файл с двумя методами «вперед» и «назад». Вот пример автоматически сгенерированной миграции:

# > manage.py schemamigration issuetracker added-status-field --auto

# 0004_added-status-field.py
class Migration:

    def forwards(self, orm):

        # Adding field 'Issue.status'
        db.add_column('issuetracker_issue', 'status', orm['issuetracker.issue:status'])       

    def backwards(self, orm):

        # Deleting field 'Issue.status'
        db.delete_column('issuetracker_issue', 'status')

Пара приятных моментов ....

• South позволяет вам откатиться к определенной миграции #, если вы хотите

• Если ваш производственный сайт находится на миграции 0002 и ваша фиксация SVN находится на 0004, South сделает 0003, а затем 0004, чтобы ускорить работу производственной базы данных.

• Если вы пошли дальше и внесли изменения сами, вы можете сказать South выполнить «поддельную» миграцию. Обычно миграционная система шипит, но это действительно упрощает гибкий контроль над вашей БД.

  manage.py migrate [appname] --fake

• Если вам нужно сделать что-то нестандартное, например, скопировать данные из столбца в другой столбец , поскольку файлы миграции - это просто файлы Python, функции прямого / обратного преобразования легко изменить.

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

  manage.py convert_ to _south [appname]

• И, конечно, как я мог забыть, моя любимая функция - автоматическое создание файлов миграции

  manage. py schemamigration [appname] [description] --auto

Gotchas

Я подумал, что должен добавить несколько советов по ошибкам, которые я сделал, когда начал работать с South. Не все на 100% интуитивно понятно.

• После тебя » Запустите команду convert_to_south в своей базе данных разработки, не забудьте запустить migrate --fake в своей производственной базе данных, иначе South сочтет ее устаревшей.

• Если вы создаете новую app, вы используете - начальный флаг

• Прекратите использование manage.py syncdb. Действительно.

• Редактирование модели - это трехэтапный процесс -

  1.) Сохранить изменения модели

  2.) Запустить schemamigration --auto

  3.) Запустить migrate для фактического внесения изменений в базу данных

Edit - Чтобы прояснить комментарии ниже, участники ядра официально проголосовали за то, чтобы South не был включен в версию 1.2. Отчасти это произошло из-за того, что автор «Юга» просил не включать его. Тем не менее, сообщество поддерживает Юг, и некоторые производители многоразовых приложений начинают включать в свои приложения миграции South.

Edit # 2 - Я сделал некоторые обновления, чтобы отразить новую структуру команд manage.py из текущей основной версии South. «startmigration» разделен на «schemamigration» и «datamigration» в зависимости от того, что вы делаете.