В настоящее время использование Django "Evolution", "Юг" лучше и стоит переключиться?

В настоящее время я использую эволюцию Django для управления эволюцией своей базы данных. Это не идеально, но я научился жить с его недостатками. Например, мне всегда приходится копировать свою производственную базу данных для тестирования, прежде чем выходить из новой схемы, потому что команда "evolve" не всегда может генерировать базу данных, которая была изменена в нескольких небольших миграциях (при тестировании я сделал A- > B- > C, но A- > C не будет развиваться правильно.)

Будет ли Юг исправлять все эти проблемы? Стоит ли стараться выпустить новый инструмент?

Ответы

Ответ 1

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

Юг должен иметь возможность правильно обрабатывать проблемы, описанные выше. Для каждого изменения в db он создает файл, который имеет 2 метода "foward" и "назад". Здесь образец автоматически сгенерировал миграцию:

# > 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')

Несколько приятных вещей об этом....

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

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

  • Если вы поехали вперед и внесли изменения самостоятельно, вы можете сказать Югу о том, чтобы выполнить "фальшивую" миграцию. Обычно миграционная система бросала бы шипение, но это позволяет легко гибко контролировать ваш db.

    manage.py migrate [appname] --fake

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

    /li >

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

    manage.py convert_ to _south [appname]

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

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

Gotchas

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

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

  • Если вы создаете новое приложение, вы используете флаг --initial

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

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

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

    2.) запустите schemamigration --auto

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

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

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