Заставить EF4.3 Code First Migrations игнорировать ожидающие миграции

У меня есть локальный экземпляр базы данных, которую я недавно создал с помощью DbContext.Database.Create(), поэтому таблица __MigrationHistory существует с записью InitalCreate, которая соответствует текущему коду.

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

Теперь мне нужно внести изменения в модель и создать соответствующую миграцию. Но когда я запускаю Add-Migration TestMigration, я получаю следующую ошибку

Unable to generate an explicit migration because the following explicit 
migrations are pending: 

[201203271113060_AddTableX, 
 201203290856574_AlterColumnY]

Apply the pending explicit migrations before attempting to generate 
a new explicit migration.

Что мне делать в этом случае? Я не могу указать инструмент Add-Migration на другую среду, потому что не гарантируется, что версия соответствует той, что у меня есть локально. Мне нужна миграция, которая соответствует только тем изменениям, которые я сделал.

Кажется, у меня есть несколько вариантов, но ни один из них не идеален:

  1. Удалите другие миграции из папки Migrations, запустите команду Add-Migration, обновите базу данных, затем восстановите старые миграции. Это просто, но кажется немного хакерским.
  2. Вернитесь к версии модели в системе управления версиями, к которой была применена первая миграция, затем создайте ее и используйте для создания базы данных. Затем получите последнюю версию, примените все миграции, и тогда я буду готов добавить свою миграцию. Это кажется большим усилием!
  3. Создайте миграцию вручную.

Есть ли у кого-нибудь предложения о том, как с этим справиться?


person Joe Taylor    schedule 29.03.2012    source источник


Ответы (5)


Мы планируем использовать вариант вашего Варианта №1...

Наша стандартная рабочая процедура заключается в создании сценария SQL для каждой миграции (используя параметр -script базы данных обновления), чтобы установить сценарии SQL для «производственных» баз данных конечных пользователей с помощью InstallShield (мы планируем использовать EF update-database только для баз данных разработчиков).

Таким образом, у нас есть как файлы Migration .cs, так и соответствующие файлы .sql для всех миграций в нашей папке Migrations.

Таким образом, вместо того, чтобы удалять миграции из папки Migrations (как вы предложили в № 1), мы используем SQL Mgmt Studio для ручного применения только тех частей файлов .sql, которые вставляются в _MigrationHistory.

Это обновляет _MigrationHistory локальной базы данных с учетом изменений, которые уже включены в эту базу данных.

Но это кладж, и мы все еще ищем лучшее решение.

ПапаКот

person DadCat    schedule 17.07.2012

То, что я обнаружил, работает лучше всего очень просто: не используйте DbContext.Database.Create() после того, как вы включили миграции. Если вы хотите программно создать новую базу данных, используйте API миграции.

var migrator = new DbMigrator(new Configuration());
migrator.Update();

Тогда у вас есть полная история миграции, и добавление дополнительных миграций работает так, как ожидалось.

person Joe Taylor    schedule 05.11.2013

Я столкнулся с той же проблемой. Если вы запустите

Update-database

а затем запустить

Add-Migration YourMigrationName

Это решает проблему

person KillerGearz    schedule 04.11.2013
comment
Это не работает, потому что более ранние операции миграции нельзя выполнять в базе данных, созданной с помощью DbContext.Database.Create(). Представьте миграцию, которая добавляет столбец, но в вашей новой локальной базе данных у вас уже есть этот столбец, поэтому вы получаете SqlException, а соответствующая строка никогда не добавляется в таблицу __MigrationHistory. Смотрите мой ответ, что я считаю правильным подходом. - person Joe Taylor; 05.11.2013

Вам либо нужно запустить «update-database» из консоли диспетчера пакетов, чтобы отправить изменения в базу данных, либо вы можете удалить файл ожидающей миграции ([201203271113060_AddTableX]) из папки Migrations, а затем повторно запустить «add-migration», чтобы создать совершенно новая миграция на основе ваших правок.

person Valynk    schedule 23.11.2015

просто исключите старый файл миграции из файлов решения.

person Ahmed Khalid Kadhim    schedule 05.04.2017