Объяснение миграторов (FluentMigrator)?

Ответ 1

Здесь много вопросов. Я отвечу на вопросы с акцентом на FluentMigrator.

Является ли это способом первоначального создания, а затем поддерживать обновления для базы данных посредством версий.

FluentMigrator - это способ контроля версий вашей схемы базы данных. Все делают это в некотором роде. Или вручную, с sql-скриптами, с помощью инструмента, такого как SqlCompare или проекта Visual Studio Database. Все эти методы легко испортить. Так легко ошибиться при выпуске новой версии и сбое системы. Миграции - лучший способ справиться с этим.

FluentMigrator позволяет вам определить изменение схемы как кода, и обычно это проверяется в исходном элементе с другими изменениями кода. Это означает, что вы можете сказать, что версия 1.XX вашей системы должна иметь версию 123 базы данных. Это означает, что если вы откатите свой код в предыдущей версии, вы также знаете, какую версию базы данных также нужно откат.

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

A Миграция - это способ описания изменения схемы базы данных. FluentMigrator создает таблицу VersionInfo и сохраняет уникальный идентификатор (номер версии) Migration после того, как был применен.

Например, если у меня два Migrations один с Id 1 и один с Id 2. Если затем я выполняю первую миграцию, тогда Id 1 будет храниться в таблице VersionInfo, и я могу посмотреть там и знать, что версия база данных - 1, а версия 2 еще не применена.

Возможность узнать, какая версия схемы базы данных очень полезна при нажатии на изменения от Test to Production или при наличии нескольких копий базы данных в Production. Например, у меня есть клиент с офисами по всему миру, и у каждого офиса есть своя копия базы данных, и все они находятся на разных версиях. Без знания версии базы данных было бы очень сложно их безопасно обновить.

В большинстве случаев мне не нужно действительно смотреть в таблице VersionInfo, FluentMigrator обрабатывает это автоматически. Он сравнивает сборку с Migrations с таблицей VersionInfo и показывает, какие изменения еще не были применены, а затем выполняет их.

Первая миграция (или исходная версия базы данных) будет содержать все таблицы, отношения и свойства, необходимые (выполняются либо плавно или используя кусок sql в script).

Исходная точка зависит от вас. У вас может быть первая миграция, которая представляет собой sql script, который вы создали из текущей базы данных. Вы могли бы также использовать один из проектов Contrib, например FluentMigrator.T4, чтобы создать свободную миграцию. Или вы можете просто решить, что существующая база данных является отправной точкой и сохраните ее копию, чтобы восстановить ее как версию 1.

Я представил FluentMigrator для многих устаревших баз данных без каких-либо серьезных проблем.

Если вы хотите нажать на изменение базы данных, вы должны создать новую метод миграции (вверх и вниз), что-то вроде добавления новой таблицы или измените поле.

Да, Up используется для применения изменения, указанного в списке "Миграция" и "Вниз". Таким образом, Up мог бы создать таблицу, а Down - удалить таблицу.

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

Для выполнения миграции доступны три runners. Бегун командной строки, задача Nant и задача MSBuild. Обычно выполняются как часть сборки script.

Класс MigrationRunner также может использоваться в коде. Вы можете сделать это, если хотите создать собственный бегун или у вас есть другие потребности (например, строить базы данных динамически или автоматически обновлять базу данных, если добавляется новая миграция).

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

Я уже ответил на это уже. Обычно для создания базы данных обычно создается sql script. Для Sql Server требуется меньше минуты, чтобы генерировать script даже для больших баз данных. Этот script может быть сохранен в файле .sql и выполнен в качестве первой миграции с использованием выражения Execute.EmbeddedSqlScript. Это работает.

Я знаю, когда nHibernate/fluent вы можете легко создавать таблицы для без необходимости определять что-либо, кроме моделей и файлы карт. Есть ли способ сделать эту конфигурацию совместимой с Migrator/Versioning?

На данный момент такой интеграции нет, и на практике я, по крайней мере, не пропущу ее. Было некоторое обсуждение о подключении Fluent NHibernate и FluentMigrator, но это было бы много работы. Это позволит создавать строительные леса для моделирования, например, EF Code First migrations. В настоящее время это не относится к дорожной карте.

Когда nhibernate/fluent отвечает за создание базы данных, я не обязательно необходимо определить каждый аспект таблиц. Готово либо через соглашение, либо через файлы сопоставления. С мигрантами я нужно было бы определить этот уровень детализации?

Да, вам нужно будет определить на этом уровне детализации. Миграции FluentMigrators - это DSL (собственный язык) для определения изменений схемы, которые переводится на sql. Вы также можете написать sql, используя выражение Execute.Sql. Переходы Entity Frameworks имеют такую ​​интеграцию, которая имеет как преимущества, так и недостатки.

Посмотрите wiki или одно из учебных пособий здесь, здесь (часть 1) или здесь ( часть 2), чтобы получить дополнительную помощь при запуске.