M
Size: a a a
2020 January 24
M
классический вариант это набор миграций dml/ddl на изменение схемы и данных. последовательно. кто то объединяет всё в одну транзакцию, кто то нет. но как правило если есть мигратор, то он все нужные операции производит сам
За объединение в одну транзакцию надо ругать пушо потом с этим танцевать - не оч приятно.
Говорю как человек который работал в проекте где схема частично описывалась метаданными и поэтому ддл и дмл слои были смешаны. И было оч тяжко
Говорю как человек который работал в проекте где схема частично описывалась метаданными и поэтому ддл и дмл слои были смешаны. И было оч тяжко
M
За объединение в одну транзакцию надо ругать пушо потом с этим танцевать - не оч приятно.
Говорю как человек который работал в проекте где схема частично описывалась метаданными и поэтому ддл и дмл слои были смешаны. И было оч тяжко
Говорю как человек который работал в проекте где схема частично описывалась метаданными и поэтому ддл и дмл слои были смешаны. И было оч тяжко
а в чем проблема генерить допустим 2 отдельные миграции, 1 на схему и след за ней на данные? и откатывать удобно и нет заморочек с несколькими способами апдейтить базу
К
а в чем проблема генерить допустим 2 отдельные миграции, 1 на схему и след за ней на данные? и откатывать удобно и нет заморочек с несколькими способами апдейтить базу
+. Мы так и делаем
К
Проблем за 7 лет небыло
К
А порядок их как сохранить? Чтобы сначала все на схему делалось а потом все на данные?
А что во флюенте проблема с порядком?
К
м я знаю как во флюент миграторе но в еф они ж у тебя накатываются последоватьно одна за другой?
+
К
К
А в чем проблема?
К
ну тогда создай миграции в таком порядке, нет?
Не получится