gelit,

суть миграций, что они должны идти один за другим.

исполнить такой же трюк с БД, как с контролем версий, когда можно смержить 100500 веток и устранить конфликты руками -- не выйдет.

дело тут не в EF.

добавляйте миграции друг за другом, по договорённости. если так вышло, что вы добавили миграцию, и получили код, где кто-то создал миграцию до вас, откатите свою миграцию и создайте снова.

если вас не тыща человек, разбросанных по земному шару, проблем не будет :)

ViPRoshVostt,

можно было бы просто сказать - ЕФ этого не умеет :)

при чём тут умение-то? ты можешь его заставить засунуть миграции в любом порядке, это просто защита от идиота. :)

Агнец за бортомEF может переклинить когда в жало работаешь, что уж говорить о команде?

Пускай миграции генерит ОДИН человек, по доменной модели - и всё. База одна - человек один - точка генерации миграций одна. И всё.

никогда проблем не было. не нагнетайте )

gelithVostt,

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

давайте ещё раз.

вам прежде, чем первый этаж построить, нужно сделать фундамент.
а вы говорите, "у нас так не получится", -- ВСМЫСЛЕ??
БД это не код, это единая структура данных: таблиц, связей, функций и т.п. всё между собой взаимосвязано.

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

как я уже и сказал, если кто-то успел сделать миграцию перед вашей, то свою откатываете, потом создаёте заново. делов на пару минут. какой ещё процесс вам тут нужен?

Агнец за бортомИбо EF один раз пройдёт update корректно, а потом (после откатов туда-сюда) - запутается в именах и вывалится с ошибкой.

с чего бы это?
откат миграции не основывается на маппинге, это конкретный сценарий, даже если ты все свои ентити грохнешь, всё сработает.

love_bach3. правильно - отказаться от миграций EF, делать их руками, например, чз FluentMigrator. миграции, которые автоматом генерятся EF - это днище.

всё днище, что не удалось осилить.

есть знакомый программер, который считает всё кроме его ЯП днищем, потому что сколько не пытался выйти за рамки своего ЯП, не получается. поэтому днище :)

Petro123hVostt,
Вы спорите про одно и то же.
Один говорит что точка миграции одна. Второй что коммиты для мерже следуют друг за другом.

лично я не спорю.

я работал в проектах, где на EF пилили много человек, БД большая и сложная, всё на code-first-миграциях и всё было нормально. автомиграции работают отлично, нужно нормально описывать модель.

проблемы с конфликтами решались на раз. затягиваешь изменения, видишь кто-то влез вперёд тебя, откатываешь свою миграцию, создаёшь заново. делов на две минуты.

также видел тех, кто не осилил, просто тупо не въехал, не сумел ни разобраться, ни понять.
они ведут в папке sql-файлики, изолировано. потом один парень из этого собираешь большой sql, чтобы накатитить на продовую БД.

кому-то по душе мартышкин труд. как говорится, не умеешь работать головой -- работай руками!