Что делает Южная миграция по сравнению с схемой миграции?
Недавно я начал копаться в документации 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
В то время как мигрирование - это реальное мясо и кости Юга, схематизация сравнена полностью необязательно. Его утилита поможет вам написать некоторые из ваших миграций (в частности, те, которые меняют схему) для вас; если вам нравится, вы можете игнорировать его и писать все сами, и в этом случае мы желаем вам удачи и счастливой печати.