migrator.net против FluentMigrator против Migsharp

Question

В настоящее время я изучаю возможные варианты среды / инструмента миграции.Мне нравится идея рубиновых миграций, на которой основаны вышеупомянутые фреймворки.

Поэтому я спрашиваю ваш опыт, мнения и, возможно, сравнение между ними.Используете ли вы их в производстве?

---

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

В любом случае, я решил использовать MigSharp в качестве базы кодакажется довольно чистым, и он довольно прост в обращении и имеет встроенную поддержку MS SQL CE.Вторым призером был бы FluentMigrator, где я не смог подготовить рабочий пример для компактного издания.

Приветствия

Answer 1

Я использую FluentMigrator на производстве и давно помогаю FM.Я думаю, что ваш вопрос к генералу;Более конкретно.Кроме того, у FM есть группа Google, которая довольно активна, если вам нужна информация о FM.

FM, как я помню, происходит от migrator.netОн использует свободный синтаксис и поддерживает несколько баз данных.Мы черпали вдохновение из рельсовых миграций, но это определенно не порт.Стоит проверить.

Одна вещь, которую я узнал, - это не помещать ваши миграции в ту же сборку, что и код приложения.Разделите их в сборку миграции и используйте ее для переноса ваших баз данных.

Кроме того, вы всегда должны работать в нескольких средах, чтобы избежать проблем, связанных с миграциями, которые напрямую связаны с производством.У меня всегда есть, по крайней мере, среда разработки и производства, и в большинстве случаев также есть среда тестирования.

Answer 2

Я использую mig #.

Это хорошо работает, но вам нужно иметь некоторые рекомендации по использованию - миграция может усложниться.

Мы используем порядковый номер в конце нашей миграции, а не метку даты и времени. Это потому, что мы не знаем, когда была установлена ​​метка даты (когда они начали набор изменений исходного кода; непосредственно перед фиксацией; некоторое время между ними), разные разработчики могли использовать разные подходы.

Такие имена, как Migration_0000034.cs, дают вам достаточно места.

Answer 3

На данный момент, я бы придерживался migrator.net.Мне нравится обещание FluentMigrator, но у него, похоже, нет более активной активной разработки, чем migrator.net (см. Проблемы и запросы запросов, которые томились на их сайте github).

Нет также простого способасделать ExecuteScalar ().Я бы добавил его, но я не хочу создавать свой собственный форк, и я не вижу причин, по которым запрос на получение доступа фактически попадет в мастер.(Execute.WithConnection - это действие, поэтому оно будет запускаться по требованию, а не тогда, когда мне нужно его запускать)

Так что я возвращаюсь на migrator.net.