Хорошо ли взаимодействуют Fluent NHibernate и migratordotnet?

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

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

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

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

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

Ваше здоровье!


.net migration fluent-nhibernate migratordotnet
person Gordon McAllister    schedule 02.06.2009    source источник
comment
Немного поздно, но для справки, есть хороший пост об использовании Fluent NHibernate для этого. На самом деле это не отвечает вашей части migratordotnet, но я нашел ее полезной при поиске похожих ответов: blog.appharbor.com/2012/06/11/   -  person autonomatt    schedule 28.11.2012

Ответы (4)


arrow_upward
7
arrow_downward

Гордон,

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

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

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

person Andrew Hanson    schedule 03.06.2009

arrow_upward
2
arrow_downward

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

person Shane Fulmer    schedule 03.06.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

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

person Alex    schedule 21.12.2009

arrow_upward
0
arrow_downward

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

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

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

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

person fostandy    schedule 30.08.2010