Pull to refresh

Comments 7

Спасибо.
Будем иметь в виду на будущее. :)
Использовали custom решение на базе T-SQL скриптов с регистрацией накатки в базе.
Надежно, но не mainstream — у новых разработчиков сложности с пониманием и сложности с грамотным написанием T-SQL.
Перешли на Fluent Migrator.
У Fluent Migrator есть свойство — если в одной миграции несколько шагов и один из шагов вызывает ошибку на сервере баз данных, Fluent лихо продолжает выполнять шаги и оценивает результат выполнения по последнему шагу (как успех). Т.е. сложные миграции желательно дробить.
Почему не стали рассматривать liquibase?(https://www.liquibase.org/)
Liquibase, насколько я знаю, с .net core не самым лучшим образом дружит.

В любом случае, все возможные существующие варианты рассмотреть не было возможности.
EF core
Разрешение конфликтов осталось на том же уровне. Необходимо выстраивать последовательность миграций и обновлять снимки БД

Не понял. Вы же сами пишете что в EF Core теперь не хранится снимок БД. А в других инструментах последовательность миграций может любой? Что-то сомневаюсь.
А для DbUp вы вообще в плюсы вписали «Конфликты также решаются с помощью SQL»

Зависимость от моделей, на основе которых сгенерированы миграции

В миграции можно написать выполнение любого необходимо sql-query. В plain-text, без зависимости от моделей.
В своё время ушли на Fluent с EF потому, что многое делает по умолчанию и не позволяет «допилить». Например нельзя задать имя DEFAULT CONSTRAINT для колонки. А иногда так уж складывается, что надо. Про отсутствии автогенерации не особо жалели. Ручками оно как-то надёжнее.
Sign up to leave a comment.