EF Migration проблемы

Question

Мы работаем с EF Миграции в одном проекте с 3-мя состояниями:

• развития: каждый разработчик имеет свою собственную базу данных
• Балетмейстер: та же база данных, как производство
• Производство: та же база данных as staging

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

Проблема возникает, когда мы загружаем проект в стадию. Нам необходимо обновить промежуточную базу данных из-за

модель поддержав контекст «XXX» изменилось с тех пор была создана база данных

Но если мы обновляем базу данных (с помощью миграции), производство бросает то же сообщение (потому что Production and Staging имеет одну и ту же базу данных).

Изменения в базе данных минимальны, поэтому было бы без проблем, если бы мы не использовали миграции EF.

Любые советы?

Answer 1

Возможно, ваша проблема с дизайном для использования одной и той же базы данных в Staggig и в Production.

Но

изменения базы данных минимальны

уже не та же база данных. Уверен, вы не можете рассчитать одно и то же значение хэша даже после small changes =)

Я думаю, что так оно и должно работать.

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

И все три разные экземпляры.

Answer 2

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

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

Вы можете избавиться от миграции - удалить таблицу Миграции (__MigrationHistory) - и синхронизировать вещи (см ниже должностей более) - но с двумя кодовыми базами, указывающие на то же Db означает one migration table - и, если коды не являются то же (с точки зрения миграции) это не сработает. Таким образом, единственным решением было бы отключить миграцию.

Однако, похоже, в конце туннеля свет.

Новые сборки от EF (предварительные выпуски EF6) имеют Code First Migrations History Table Customization.

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

Для более сложных сценариев - как у вас есть - это может быть решением

отмечают, что это не подтверждается - но я думаю, что они положили его в там тех самых причин.

А «решение псевдо» будет выглядеть следующим образом ...

• сделать две фабрики - для постановки и производства - каждый создает различные «миграции таблицы»,
• каждого развертывания - имеет свой собственный миграции (в коде) и истории миграции в базе данных,
• вы можете вручную настроить конкретную таблицу миграции для, например, постановка - при необходимости - без ущерба для другого,
• убедитесь, что ваша база данных «достаточно похожи», так что оба коды/Миграции могут работать бок о бок

Это может работать, я думаю. ..

---

How to Synchronize Db/Code - Summary
How to Synchronize Db/Code - Long Version