Use EF for modular data migration and migration of existing databases
Note: This article is intended for readers who have already understood EF's migration function and know how to input commands in the console.
Problem
Recently, the company's project architecture was rectified using the ABC, and we wanted to replace the previous manual script with the automatic migration of EF.
Why?
See:
Needless to say, we need to prepare a bunch of Database Upgrade scripts for the release of major versions. This is a nightmare.
Using ef will automatically help us complete database migration, and we can simply maintain the migration script.
Because we are an offline project and many customers are using the old version, we have to consider the problem of existing tables.
For existing databases, there will always be problems with Table_XXX during migration,
This is easy to understand, because even an existing database
As long as there is no _ migrationhistory table, it will regard it as a new library and execute the creation script.
The second problem is that the company needs to iterate and release some functional modules separately. Simply put, some functions are installed in Plug-in packages.
Friends who have used Orchard will surely know that its modular mechanism can independently create and maintain their own tables,
Yes. Now we want to implement similar functions.
Solution
1. Migration of existing databases
What should I do if I upgrade existing data?
In fact, it is very easy to choose the latest release version as an initial version of EF migration. All database upgrades to the initial version or all new installations are carried out using DDL scripts.
After selecting the latest release version, we will use
Add-Migration Initial
Create an initialization migration script.
Then delete all content in the Up and Down methods, as shown below:
Then we can start the development of the current iteration. After DbContext is modified, we can use
Add-Migration XXXXXX_X.X.X (the name of the current version can be described)
Create a migration script for the current development version, as shown below.
Next, let the program be automatically upgraded during program initialization,
What I know can be done in the following ways:
1. Run the migration exe file on the official website.
2. Control the migration through the program.
3. Run Update-Database on the nuget console.
As an offline project, the third method obviously cannot be used, and the first method needs to include the exe and write some scripts, Which is troublesome.
The second method can be implemented by two classes:
1, DbMigrator
var dbMigrator = new System.Data.Entity.Migrations.DbMigrator(new Migrations.Configuration()); dbMigrator.Update();
2, MigrateDatabaseToLatestVersion
new MigrateDatabaseToLatestVersion<CoreServiceDbContext, Configuration>().InitializeDatabase(new CoreServiceDbContext());
The difference is that the former can select an updated version, and the latter can choose either of them if there is no special requirement.
The code at both ends of the above can be done when the program is initialized. Friends who use the ABP framework can do this in the PreInitialize of the Data module.
In this way, the existing database is automatically upgraded.
2. modular data migration.
This problem is actually well solved. Each module can use different contextkeys When configuring its own EF migration settings, as shown below:
(This is the migration setting for the main business functions)
(For a module)
The migration table after installation is as follows:
It can be seen that each module has different contextkeys and the migration records do not affect each other.
The only pity is that we have to manually copy the entire database during installation because Mysql does not support DDL transaction management.
If you use migration in the SQLServer environment, EF will automatically start the transaction. Oracle is not familiar with it. If you have already verified the transaction, please leave a message.