Хорошо ли играют Fluent NHibernate и migratordotnet вместе?

Question

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

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

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

В духе СУХОЙ, как я могу получить изменения моей схемы из моих отображений в Fluent Nhibernate? Возможно ли это?

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

Ура! * * 1013

Answer 1

Гордон,

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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