Что делает Южная миграция по сравнению с схемой миграции?

Недавно я начал копаться в документации South и обнаружил, что он имеет два разных типа миграции:

schemamigration
datamigration

В результате моего невежества я всегда использовал схемы для всего. Другими словами, даже если бы у меня было что-то действительно "миграция данных", я просто использовал схему юг для преобразования данных (без видимых последствий).

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

Ответ 1

Для ведущего разработчика South:

Здесь вы можете увидеть разницу: https://bitbucket.org/andrewgodwin/south/src/b3ed126b19a2/south/v2.py

Как видно из этого, единственное отличие состоит в том, что миграция данных не dry-run, если у вас есть база данных, которая требует его (MySQL). В противном случае, есть небольшая разница, по крайней мере на данный момент - руководство команды отличаются, хотя (все это касается разделения пользовательского интерфейса, по существу).

Ответ 2

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

Изменить: из http://south.aeracode.org/docs/commands.html#schemamigration

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