Зачем использовать Юг во время начальной разработки?

Question

Я задаюсь вопросом о преимуществах использования (django) South во время интенсивной начальной разработки проекта

На ранних этапах разработки обычно происходит быстрое изменение модели, частое ветвление и слияние (особенно если вы используете стратегию разработки, такую ​​как git-flow) и очень мало, если таковые имеются, хранимых данных. Почему вы хотите сохранить эти первоначальные изменения модели? Каковы преимущества / недостатки?

У меня сложилось впечатление, что легче подождать, пока разработка завершится (и у вас есть данные, которые вы действительно хотите сохранить), прежде чем активировать Юг и выполнить первоначальную миграцию. Возможно ли это сделать? Хотели бы вы сделать это?

Answer 1

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

Если вы работаете в одиночку (и не беспокоитесь о развертывании)это не проблема, и вы можете подождать до последнего возможного момента для создания миграции.

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

Кроме того, syncdb не подходит, если вы просто изменяете поле.Это невероятно раздражает, когда приходится сдувать таблицу только для добавления, удаления или изменения полей.

Если у меня есть куча миграций схем, которые я добавил, иногда я их объединяю (откат, удаление и созданиеновая гигантская миграция) в единую миграцию.Но обычно количество миграций меня не беспокоит, потому что они мне ничего не стоят на самом деле.

Answer 2

Я обнаружил, что Юг так же полезен во время разработки, как и впоследствии, именно потому, что поля таблицы меняются так часто. Довольно неприятно, когда приходится отбрасывать таблицу и заново создавать ее с помощью syncdb, просто чтобы добавить одно поле, особенно если у вас есть какие-либо тестовые данные. (Вы также можете просто изменить таблицу непосредственно в вашей СУБД, но тогда вы должны быть осторожны, чтобы использовать тот же тип поля, который ожидает Django, установить соответствующие атрибуты, как ON DELETE, и т. Д.). Кроме того, если кто-то еще работает над проектом, вы должны обязательно сказать им, чтобы они делали точно такие же изменения в своей копии базы данных. Юг делает все намного проще, ИМО.

При этом было бы неплохо, если бы у South была возможность удалить все предыдущие миграции, поэтому вы можете начать с чистого листа, когда заканчиваете начальный dev и начинаете добавлять реальные данные. Но в конечном итоге эти дюжина дополнительных файлов миграции на самом деле ничего не стоят.

Answer 3

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

Answer 4

Хорошая новость - по состоянию на 2 сентября 2014 года миграции стали частью ядра Django, выпуск 1.7.

https://docs.djangoproject.com/en/dev/releases/1.7/

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

Answer 5

Определенно можно использовать юг с определенного этапа и выполнить первоначальную миграцию. SOuth документы здесь: http://south.aeracode.org/docs/tutorial/part1.html#converting-existing-apps

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