Скрипты обратной миграции больше нужны для разработчиков и DBA, например чтобы можно было развернуть эталоную структуру и сгенерировать diff'ы во время плановых сервисных работ с сервером.
Клиенту миграции назад не нужны. Именно поэтому мой самописный гуевый runner умеет устанавливать миграции только вперед.
Генерировать различия нам, к сожалению, не подходит по двум причинам:
1. Около 100 клиентов, у каждого свой независимый сервер. Черт его знает что там творится со структурой и данными.
2. Не до всех серверов еще и доступ есть. Некоторые в такой глуши находятся, что особо к ним не наездишься (стоимость поддержки не окупит таких путешествий).
Я нигде не говорил, что не люблю DML. Более того, у FluentMigrator'а очень скромные возможности DML.
Если кто-то любит чистый SQL (PL/SQL, T-SQL и т.д.), то FluentMigrator позволяет выполнять прикрепленные скрипты.
Вы меня удивляете. С этой точки зрения ваши запятые между параметрами ничем не лучше.
Код миграции в FluentMigrator'е читается не чуть не сложнее чем в Вашем. К тому же Ваш проект из серьезных СУБД поддерживает только SQL Server. Если добавите поддержку Oracle (который больше всего меня интересует) и еще парочки СУБД, тогда можно будет сравнивать удобство API.
Клиенту миграции назад не нужны. Именно поэтому мой самописный гуевый runner умеет устанавливать миграции только вперед.
1. Около 100 клиентов, у каждого свой независимый сервер. Черт его знает что там творится со структурой и данными.
2. Не до всех серверов еще и доступ есть. Некоторые в такой глуши находятся, что особо к ним не наездишься (стоимость поддержки не окупит таких путешествий).
Я нигде не говорил, что не люблю DML. Более того, у FluentMigrator'а очень скромные возможности DML.
Если кто-то любит чистый SQL (PL/SQL, T-SQL и т.д.), то FluentMigrator позволяет выполнять прикрепленные скрипты.
Код миграции в FluentMigrator'е читается не чуть не сложнее чем в Вашем. К тому же Ваш проект из серьезных СУБД поддерживает только SQL Server. Если добавите поддержку Oracle (который больше всего меня интересует) и еще парочки СУБД, тогда можно будет сравнивать удобство API.
И как между собой связаны Fluent и «непродираемый» API?