Активны ли Fluent NHibernate и migratordotnet вместе?

Я люблю Fluent NHibernate для создания своих БД и до сих пор не нашел ограничений, которые остановили меня на моих треках.

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

Я хотел бы отслеживать эти изменения DDL amd DML в "migrations", используя инструмент, например migratordotnet. Но мой вопрос: возможно ли совместное использование этих двух инструментов (или аналогичных инструментов)?

В духе DRY, как я могу получить мои изменения схемы из моих сопоставлений в Fluent Nhibernate? Возможно ли это?

Или это лучший подход, чтобы оставить создание схемы в таком инструменте migratordotnet и оставить Fluent NHibernate только с возможностью сопоставления? Хм, это похоже на лучшее разделение проблем на уровне инструмента.

Ура!

Ответы

Ответ 1

Гордон,

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

Я по-прежнему буду использовать SchemaUpdate для быстрых прототипов, но как только я начну проект серьезно, я использую только migratordotnet.

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

Ответ 2

Я также сталкиваюсь с этой же проблемой, где я не хочу поддерживать миграцию (используя migratordotnet) и мои файлы сопоставления независимо. Единственная полезная вещь, которую я нашел до сих пор, это NHibernate SchemaUpdate, но она не обрабатывает удаление столбцов или таблиц. Для этих типов изменений вам все равно придется вручную переносить миграцию. Сейчас я склоняюсь к использованию migratordotnet исключительно для изменений базы данных, а не для смешивания SchemaUpdate генерировать DDL и миграции. Это все еще кажется склонным к ошибкам, поскольку вы можете неправильно преобразовать изменения отображения/домена в миграции.

Ответ 3

У меня такая же проблема. Вот мой текущий рабочий процесс, который позволяет избежать SchemaUpdate:

  • создать базу данных с нуля (при внесении любых изменений)
  • сохранить все справочные данные в электронных таблицах
  • перезагрузить все данные через специальный проект командной строки 'dataloader'

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

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

  • Как только цикл dev закончен, я беру клон производственной базы данных. База данных Prod предназначена для чтения только для продолжительности обновления (нормально для моего приложения... не уверен в более важных для времени приложениях).
  • Используйте SQL Compare для переноса изменений и данных через dev в базу данных prod.
  • нажмите, чтобы проверить.
  • Если тест пройден, нажмите на производство.

Это не идеально и использует коммерческий продукт SQL Compare. Он работает для меня, но я хотел бы услышать некоторые идеи.

Ответ 4

Да - в основном. Я успешно использую как FNH, так и migratordotnet для толстого настольного клиента, и он работает достаточно хорошо. Мне пришлось изменить его на две вещи:

  • Чтобы разрешить встраивание sql-соединения в TransformationProvider (или, более точно, SQLiteTransformationProvider)

  • удалите ссылки на другие не sqlite TransformationProviders, как если бы я попытался упаковать его с моим приложением, он бы выбросил различные ошибки из-за невозможности найти Oracle, Postgres и т.д.

  • Это специфичный sqlite - взломайте его, чтобы лучше разобрать sqlite create table statements. К сожалению, он не может обрабатывать инструкции create table формы CREATE TABLE FOO(id INT, ..., primary key(id)) (в отличие от CREATE TABLE FOO(id INT PRIMARY KEY, ...), которую он обрабатывает). Объедините это с тем, как он выполняет удаление столбцов (создайте столбец столбцов таблицы, передайте данные, удалите оригинал и переименуйте новый в оригинал), это означает, что вы можете получить довольно неприятное поведение, например, удаление столбца на столе, что делает ваш основной столбец ключа непервичный ключевой столбец.