БД до требуемой версии.
1) На практике с такой потребностью пока не сталкивался. Есть мнение, что FluentMigrator может в такое.
2) Что в данном случае Вы понимаете под diff-ом? Было бы интересно узнать об этом больше, пожалуй. Не пользовался.
3) Есть опыт использования EntityFramework и FluentMigrator. В целом связка Linq2Db+FluentMigrator выглядит гибче, чистый SQL при этом использовать не гнушаемся в сложных ситуациях, которые не покрывает типизированный Fluent API. Из преимуществ типизированного SQL — страхует от опечаток в простых ситуациях, которых обычно больше всего.
"При новом запуске приложения" - у вас одно приложение использует БД? 1) Я тоже. По-моему, достаточно одного направления изменений - от любой версии к актуальной. 2) Подход основан на знании текущей схемы БД (создающий ее sql-скрипт хранится одним файлом в репозитории, при необходимости обновляется) и предполагает, что главное - уметь любую БД обновить/откатить именно до нее. Обновление/откат делаются через сравнение снимков схем БД-источника и целевой БД, затем - автогенерацию скрипта разницы между ними (ALTER, которые приведут целевую к состоянию источника), затем - применение этого скрипта к целевой БД. Например, RedGate SQL Compare, Visual Studio Database Project. 3) Чем FluentMigrator гибче чистого SQL?
Обсуждают сегодня