Комментарии 12
Когда ж уже народ угомонится со всем этим 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 }
}
};
}
}
К чему вы здесь привели свой код. Вы считаете что он чем-то лучше?
И как между собой связаны Fluent и «непродираемый» API?
И как между собой связаны Fluent и «непродираемый» API?
Да, я считаю, что он лучше: там меньше «церемоний» и больше дела.
А непродираемость заключается во всех этих точках: Create.Table.WithColumn.AsInt64.Nullable.PrimaryKey.
FI хорош в меру — от силы пара-тройка вызовов.
А непродираемость заключается во всех этих точках: Create.Table.WithColumn.AsInt64.Nullable.PrimaryKey.
FI хорош в меру — от силы пара-тройка вызовов.
Вы меня удивляете. С этой точки зрения ваши запятые между параметрами ничем не лучше.
Код миграции в FluentMigrator'е читается не чуть не сложнее чем в Вашем. К тому же Ваш проект из серьезных СУБД поддерживает только SQL Server. Если добавите поддержку Oracle (который больше всего меня интересует) и еще парочки СУБД, тогда можно будет сравнивать удобство API.
Код миграции в FluentMigrator'е читается не чуть не сложнее чем в Вашем. К тому же Ваш проект из серьезных СУБД поддерживает только SQL Server. Если добавите поддержку Oracle (который больше всего меня интересует) и еще парочки СУБД, тогда можно будет сравнивать удобство API.
На одном из предыдущих проектов мы сделали утилитку. Утилитка делала следующее:
— брала папку «diffs», находящуюся под SVN, вынимала оттуда все файлы с ревизиями, на которых был создан файл (не изменен, это важно)
— лезла в базу, в спец. таблицу, и смотрела последнюю ревизию, на которую были успешно выполнены скрипты
— прогоняла все скрипты с этой ревизии. Если какой-то скрипт давал сбой — все останавливалось. Это давало возможность поправить скрипт не изменяя порядка
— затем из базы сносились все хранимки, вьюхи, функции и все такое
— из других папок брались скрипты для создания хранимок, вьюх и прочего. Если прогон скрипта давал ошибку «нет зависимого объекта», скрипт ставился в начало очереди. Так мы разрулили связи между объектами (если какая-нибудь хранимка использует вьюху или другую хранимку, например)
Скрипты были обычные SQL-ки, плюс была возможность заливать данные из CSV, это юзалось для справочников.
Я это все к чему. Такая система нужна, безусловно. Но все что делается на этом поприще — не в тему вообще. Вместо того, чтобы решать всякие нужные вещи (апдейт хранимок тот же, привязка к SVN и прочее), все зачем-то придумывают замену DML. Чем вам DML-то не угодил?
— брала папку «diffs», находящуюся под SVN, вынимала оттуда все файлы с ревизиями, на которых был создан файл (не изменен, это важно)
— лезла в базу, в спец. таблицу, и смотрела последнюю ревизию, на которую были успешно выполнены скрипты
— прогоняла все скрипты с этой ревизии. Если какой-то скрипт давал сбой — все останавливалось. Это давало возможность поправить скрипт не изменяя порядка
— затем из базы сносились все хранимки, вьюхи, функции и все такое
— из других папок брались скрипты для создания хранимок, вьюх и прочего. Если прогон скрипта давал ошибку «нет зависимого объекта», скрипт ставился в начало очереди. Так мы разрулили связи между объектами (если какая-нибудь хранимка использует вьюху или другую хранимку, например)
Скрипты были обычные SQL-ки, плюс была возможность заливать данные из CSV, это юзалось для справочников.
Я это все к чему. Такая система нужна, безусловно. Но все что делается на этом поприще — не в тему вообще. Вместо того, чтобы решать всякие нужные вещи (апдейт хранимок тот же, привязка к SVN и прочее), все зачем-то придумывают замену DML. Чем вам DML-то не угодил?
Кстати, в случае MSSQL, diff-ы на DML делаются в два счета. Открываем схему базы в Management Studio, меняем там что нужно (добавляем поля, таблицы, связи, индексы и т.п.), и потом сверху давим кнопку «generate script». Все.
И еще — зачем нужны скрипты обратной миграции? Если в базе есть данные, то в общем виде их никак не сделать. Если данных нет — проще все с нуля прогнать от начала.
И еще — зачем нужны скрипты обратной миграции? Если в базе есть данные, то в общем виде их никак не сделать. Если данных нет — проще все с нуля прогнать от начала.
Генерировать различия нам, к сожалению, не подходит по двум причинам:
1. Около 100 клиентов, у каждого свой независимый сервер. Черт его знает что там творится со структурой и данными.
2. Не до всех серверов еще и доступ есть. Некоторые в такой глуши находятся, что особо к ним не наездишься (стоимость поддержки не окупит таких путешествий).
Я нигде не говорил, что не люблю DML. Более того, у FluentMigrator'а очень скромные возможности DML.
Если кто-то любит чистый SQL (PL/SQL, T-SQL и т.д.), то FluentMigrator позволяет выполнять прикрепленные скрипты.
1. Около 100 клиентов, у каждого свой независимый сервер. Черт его знает что там творится со структурой и данными.
2. Не до всех серверов еще и доступ есть. Некоторые в такой глуши находятся, что особо к ним не наездишься (стоимость поддержки не окупит таких путешествий).
Я нигде не говорил, что не люблю DML. Более того, у FluentMigrator'а очень скромные возможности DML.
Если кто-то любит чистый SQL (PL/SQL, T-SQL и т.д.), то FluentMigrator позволяет выполнять прикрепленные скрипты.
Скрипты обратной миграции больше нужны для разработчиков и DBA, например чтобы можно было развернуть эталоную структуру и сгенерировать diff'ы во время плановых сервисных работ с сервером.
Клиенту миграции назад не нужны. Именно поэтому мой самописный гуевый runner умеет устанавливать миграции только вперед.
Клиенту миграции назад не нужны. Именно поэтому мой самописный гуевый runner умеет устанавливать миграции только вперед.
Для своего фреймворка я реализовал похожий мигратор, основанный на fluent-интерфейсе. Для Java есть достаточно известный LiquiBase, но он основан на XML.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FluentMigrator — система версионных миграций