Перемещение лесов с изменением контекстного ключа

Question

Я изменил проект, который привел к изменению имени пространства имен контекста базы данных и связанной конфигурации кода первого. В этот момент у меня была одна миграция с помошью, «InitialCreate», и поэтому таблица моей базы содержала одну строку с некоторыми MigrationId и ContextKey, содержащую имя пространства имен и имя класса класса Configuration.

После того, как я переместил вещи, выполнение Get-Migrations не получило никаких результатов, после изменения ContextKey согласно совету моего коллеги, миграция «InitialCreate» была правильно перечислина.

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

Answer 1

Я был застрял в этом в течение долгого времени и спросил-и-ответил-он here. В EF Docs вы можете найти объяснение о контекстных клавиш here .Вы должны создать пользовательскую конфигурацию миграции, как это:

public class MyMigrationConfiguration : DbMigrationsConfiguration<MyMigrationContext> 
{ 
    public MyMigrationConfiguration() 
    { 
     AutomaticMigrationsEnabled = false; 
     AutomaticMigrationDataLossAllowed = false; 
     MigrationsNamespace = "My.Migrations.Assembly"; 
     MigrationsDirectory = "My/Migrations/Directory"; 
     ContextKey = "MyContexKey"; // You MUST set this for every migration context 
    } 
} 

Answer 2

Я узнал, что класс DbMigrationsConfiguration{TDbContext} имеет свойство, называемое ContextKey (EF6 и его функция «многопользовательские миграции»), которая позволяет мне явно задать контекстный ключ. Это свойство будет установлено, если я использовал параметр -ContextTypeName команды Enable-Migrations в консоли диспетчера пакетов.

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

Answer 3

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

Наконец я решил проблему с невозможностью добавить новую миграцию или сохранить базу данных в актуальном состоянии или миграции схемы в исходное состояние, делая эти шаги:

• Я изменил пространства имен в объединенном проекте ко всем переходам и самой конфигурации к новому значению пространства имен.

• я выполнил следующее заявление в отношении базы данных:

  USE [DatabaseName] 
  
  GO 
  
  UPDATE [dbo].[__MigrationHistory] 
      SET [ContextKey] = N'NewNamepacePlusConfigurationClassName'  
  WHERE ContextKey= N'NamepacePlusConfigurationClassName' 
  
  GO 
  

• Я строю проект, содержащий миграции с конфигурацией

Теперь все работает, как и ожидалось, я даже в состоянии изменить схему в обратном направлении с помощью заявления

Update-Database -TargetMigration PreviousMigration