FluentMigrator — система версионных миграций

[ostapbender]

Когда ж уже народ угомонится со всем этим Fluent'ом. API ж совершенно непродираемый получается.

    public class V1 : MigrationDefinition
    {
        public override Migration Up()
        {
            return new Migration {
                new Table("example_table") {
                    { "id", DbType.Int16, NotNull, PrimaryKey },
                    { "name", DbType.AnsiString, 100, Null },
                },
                new Index("example_table", Unique) {
                    { "name", Asc }        
                }
            };
        }
    }

[tabushi]

К чему вы здесь привели свой код. Вы считаете что он чем-то лучше?
И как между собой связаны Fluent и «непродираемый» API?

[ostapbender]

Да, я считаю, что он лучше: там меньше «церемоний» и больше дела.

А непродираемость заключается во всех этих точках: Create.Table.WithColumn.AsInt64.Nullable.PrimaryKey.

FI хорош в меру — от силы пара-тройка вызовов.

[tabushi]

Вы меня удивляете. С этой точки зрения ваши запятые между параметрами ничем не лучше.
Код миграции в FluentMigrator'е читается не чуть не сложнее чем в Вашем. К тому же Ваш проект из серьезных СУБД поддерживает только SQL Server. Если добавите поддержку Oracle (который больше всего меня интересует) и еще парочки СУБД, тогда можно будет сравнивать удобство API.

[jakobz]

На одном из предыдущих проектов мы сделали утилитку. Утилитка делала следующее:

— брала папку «diffs», находящуюся под SVN, вынимала оттуда все файлы с ревизиями, на которых был создан файл (не изменен, это важно)

— лезла в базу, в спец. таблицу, и смотрела последнюю ревизию, на которую были успешно выполнены скрипты

— прогоняла все скрипты с этой ревизии. Если какой-то скрипт давал сбой — все останавливалось. Это давало возможность поправить скрипт не изменяя порядка

— затем из базы сносились все хранимки, вьюхи, функции и все такое

— из других папок брались скрипты для создания хранимок, вьюх и прочего. Если прогон скрипта давал ошибку «нет зависимого объекта», скрипт ставился в начало очереди. Так мы разрулили связи между объектами (если какая-нибудь хранимка использует вьюху или другую хранимку, например)

Скрипты были обычные SQL-ки, плюс была возможность заливать данные из CSV, это юзалось для справочников.

Я это все к чему. Такая система нужна, безусловно. Но все что делается на этом поприще — не в тему вообще. Вместо того, чтобы решать всякие нужные вещи (апдейт хранимок тот же, привязка к SVN и прочее), все зачем-то придумывают замену DML. Чем вам DML-то не угодил?

[jakobz]

Кстати, в случае MSSQL, diff-ы на DML делаются в два счета. Открываем схему базы в Management Studio, меняем там что нужно (добавляем поля, таблицы, связи, индексы и т.п.), и потом сверху давим кнопку «generate script». Все.

И еще — зачем нужны скрипты обратной миграции? Если в базе есть данные, то в общем виде их никак не сделать. Если данных нет — проще все с нуля прогнать от начала.

[tabushi]

Генерировать различия нам, к сожалению, не подходит по двум причинам:
1. Около 100 клиентов, у каждого свой независимый сервер. Черт его знает что там творится со структурой и данными.
2. Не до всех серверов еще и доступ есть. Некоторые в такой глуши находятся, что особо к ним не наездишься (стоимость поддержки не окупит таких путешествий).

Я нигде не говорил, что не люблю DML. Более того, у FluentMigrator'а очень скромные возможности DML.
Если кто-то любит чистый SQL (PL/SQL, T-SQL и т.д.), то FluentMigrator позволяет выполнять прикрепленные скрипты.

[tabushi]

Скрипты обратной миграции больше нужны для разработчиков и DBA, например чтобы можно было развернуть эталоную структуру и сгенерировать diff'ы во время плановых сервисных работ с сервером.
Клиенту миграции назад не нужны. Именно поэтому мой самописный гуевый runner умеет устанавливать миграции только вперед.

[Shedal]

Ну почему же. Клиентам вполне может быть нужен откат на предыдущую версию, к примеру, если в новой версии уже после выката в продакшн обнаружен критический баг, который не даёт приложению нормально работать.

[tabushi]

Кому-то — вполне возможно. Но нашим клиентам я такой возможности не дам, потому как многие из них не обременены знаниями в IT.

[konsoletyper]

Для своего фреймворка я реализовал похожий мигратор, основанный на fluent-интерфейсе. Для Java есть достаточно известный LiquiBase, но он основан на XML.

[tabushi]

Для Java значит. Спасибо, запомню.