All geek questions in one place

Forest migration with context key change

I restructured my project, which led to a change in the name of the database context namespace and the associated configuration of the first code. At that moment, I had one migration using "InitialCreate", and so my __MigrationHistory database contained one row with some MigrationId and ContextKey containing the namespace name and class name of the Configuration class.

After I moved things, the implementation of Get-Migrations did not get results, after changing the ContextKey in accordance with my colleague's advice, the migration "InitialCreate" was correctly listed.

What steps should I take during the changes, so the continuity of my migrations was not broken, which prevented renaming ContextKey manually? Obviously, this does not matter much for one applied migration, but for dozens of applied migrations it would be a huge pain.

+5
source share
3 answers

I was stuck in this for a long time and asked and answered, he is here . In the EF docs you can find an explanation about the context keys here . You must create a custom migration configuration as follows:

  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 } }
+12
source

I found out that the DbMigrationsConfiguration{TDbContext} class has the ContextKey property (EF6 and its "multi-user migration" function), which allows me to explicitly set the context key. This property will be set if I used the -ContextTypeName parameter of the Enable-Migrations command in the package manager console.

It does not seem that the context key can be changed after applying the first migration, however, with the ability to set the context key in this way after changing the name of the configuration class type, this is almost unnecessary if you can allow some inconsistency in your database.

+3
source

I had two separate database projects - one of which contains the model and the display, and the other only with the migration settings and all the migrations. I combined a project containing migrations into a project containing a model, etc.

Finally, I solved the problem of the inability to add a new migration or update the database or transfer the schema to its previous state by following these steps:

  • I changed the namespaces in the combined project to all migrations and configurations with the new namespace value.

  • I followed the following instructions for the database:

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

  • I am creating a project containing configuration migrations

Now everything works as expected, I can even change the circuit back using the operator

 Update-Database -TargetMigration PreviousMigration
+2
source

Source: https://habr.com/ru/post/1209099/

More articles:


All Articles