Code-mode Migration Update database based on existing database __ database

The content discussed in this article is based on the EF4.1 version. The existing database discussed in the article is not created by EF. This article assumes that you have a certain understanding of the code one migration, and if you do not understand the code one migration update database, you can view Migrate the update database in asp.net MVC Code-in-one mode.

The article covers the following topics:

1. Create the Model

2. Mobility

3. Add an initial migration

A, use the existing schema as a starting point

b, with an empty database as a starting point

4, note the point:

A, the default/computed name may not match the existing schema

b, not all database objects are shown in model

First, create the model

The first step is to create an existing database with the goal of the code primary model.

Note: In this topic, it is important to follow the remaining steps before making any changes to the model, and your model needs to modify the database schema. The following steps require synchronization model and database schema.

Ii. Mobility

The next step is to migrate the data. You can do this by running the enable-migrations command in the NuGet Package Manager console.

This command will create a folder named Migrations in your solution and create a class named configuration in the folder. The configuration class is used to configure data migration for an application.

Third, add an initial migration

Once you have created the database migration and applied to the local database, you may also want to apply these changes to other databases. For example, your local database might be a test database, and you might end up applying these changes to a production database or other developer test database. There are two options for this step, and you should choose depending on whether the other database's schema is currently empty or matches the schema of the local database.

Way one: Use an existing schema as a starting point (or as a start)

You should use this method when other database migrations will be applied to local databases that have the same schema. For example, if your current local test database matches the V1 production database, you will apply these migrations to update the production database to V2.

Mode two: With an empty database as beginning (or as starting)

When a database migration is applied to an empty database (or a nonexistent database), you should choose this method. For example, if you use a test database to develop your application, you do not use database migration after completion, but you create a production database from scratch.

Four, the concrete operation of two kinds of way

Mode one:

The Code-Database migration stores the latest changes to the model through a snapshot of the model. Since we assume that the database is already the pattern of the current model, we will generate an empty (operation) migration with the current model as a snapshot.

1, run the add-migration initialcreate-ignorechanges command in the Package Manager console. This command creates an empty migration with the current model as a snapshot.

2, running the update-database command in the Package Manager console. This command will apply the initial migration created to the database. If the actual migration does not contain any changes, then simply add a record to the __migrationshistory table to indicate that the migration has been applied.

Mode two:

In this way, we need to use migrations to create the entire database from scratch-including tables that already exist in the local database. We will generate an initial migration that contains this logic and create it with an existing schema. Then, the migration is applied to our existing database.

1, run the add-migration initialcreate command in the Package Manager console. This command creates a migration in the existing schema.

2. Comment out all code for the up method in the newly created migration. This allows us to apply the resulting migration to the local database and EF does not create all the tables that already exist.

3, running the update-database command in the Package Manager console. This applies the initialcreate migration in the database. Because the migration does not actually contain any changes, it simply adds a record to the __migrationshistory table to indicate that the migration has been applied.

4, cancel the up method in the comment out of the code. This means that a schema that already exists in the local database when the migration is applied to a later database will be applied through migration.

V. Matters of attention

1. The default/predicted column or table name matches the existing database

The migration explicitly specifies the name for the tables and columns that will be created for migration. However, when using this migration, these specified default names are applied to other objects in the database. Indexes and foreign KEY constraints are also included in the migration. When targeting an existing schema, these default names may not match the actual database.

Note the following points:

A, if the choice of the way a

If your model changes in the future, you need to change or delete the database object that is named different from the other, and you need to modify the scaffolding migration program to specify the correct table or column name. Migrations APIs have overloaded methods that can be modified by modifying optional parameters. For example, your existing database might have a post table containing a BLOGID foreign key column named Indexfk_blogid. However, if you use the default name in migration, it will be renamed to Ix_blogid. If you modify the model will cause the deletion of this index, you need to modify the scaffolding dropindex to specify the index named Indexfk_blogid.

b, if you choose the way two

(1) A Down method that attempts to perform an initial migration against your local database may fail because the migration program will attempt to delete the index and foreign keys with the correct name. This will only affect your local database or table, and other databases or tables will be created from scratch using the up method in the initial migration.

If you want to downgrade your existing database to an empty state, manual implementation is the easiest way that you can manually delete the database or all the database tables. All the database objects are then recreated and named the default name, so that the problem does not occur.

(2) If your model changes in the future you need to change or delete it and other named different database objects, the program for your local database will not work correctly, because the database object name does not match the default name. However, a program for a database created from scratch can work because the name used by the database object is the default name in the migration.

You can also make these changes manually in the local database, or consider using migrations to create your database from scratch.

(3) A database created using the up method in the initial migration may be significantly different from your local database because the name that is constrained to the default name by index and foreign keys is used. You can also get an extra index as a migration will create an index with the default foreign key column--the database created may not be your original local database.

2, not all database objects are in the model to be out of the

database objects that are not represented in model are not processed by migrations. These database objects that are not represented in model include views, stored procedures, permission licenses, tables, indexes, and so on.

Note the following points:

A, whether you choose the mode one or the way two, if you change the model to modify or delete these additional objects, migrations will not know what happened to the changes. For example, if you delete a column from an additional object, migrations will not know what you are deleting. If you want migrations to know the changes that have occurred, you need to manually add the deleted columns to the scaffolding migration.

b, if you choose Mode Two, these additional objects will not be created by the initial migration up method.

If you want the up and down methods to listen for these additional objects, you can modify the up and down methods. For objects, not initially supported in the Migrations API, such as views, you can use the Dbmigration.sql method to execute SQL to create or delete these objects.