An Entity Framework Core migration brings a database schema into line with an application's C# data model. Creating a migration generates a C# class containing the changes needed to prepare or modify the database; applying it executes those changes. This avoids hand-writing SQL each time the model changes. section 7.2.6 section 17.5.4
For an initial database, work from the project folder:
- Configure the Entity Framework Core database context and install the required provider, design package, and dotnet-ef tool. section 18.2.1 section 7.2.7
- Run `dotnet ef migrations add Initial`. The generated classes appear in a Migrations folder; Initial is the conventional first name. section 7.2.6 section 17.5.4
- Run `dotnet ef database update` to create or prepare the database. SQL statements appear in command output or application logs. section 17.5.4 section 18.2.5
Evolving an order schema
To store orders, add `DbSet<Order> Orders => Set<Order>();` to the context and run `dotnet ef migrations add Orders`. Entity Framework Core compares a new model snapshot with the previous version and generates the change. Later, adding a `Shipped` property calls for another migration, such as `dotnet ef migrations add ShippedOrders`. Creating either migration does not itself apply it: run a database update, or call `Database.Migrate()` at startup as the seed routine does. section 9.3.4 section 10.2.1 section 7.2.7
Listing 38.7 Creating and applying the database migration
dotnet ef migrations add --context IdentityContext Initial dotnet ef database update --context IdentityContext
When an application has multiple database contexts, specify `--context` for both creation and application so the Identity migration targets the intended database. section 38.2.3
If development changes leave the schema and migrations out of sync, dropping and recreating the database can be a quick reset. It deletes stored data; never use that shortcut on a production Identity database containing user credentials. section 9.3.4 section 38.2.3
