EF Migrations series
- Using Entity Framework to Create a Database
- Adding Indexes with EF Migrations
- Updating a Table with EF Migrations
- Indexes in Code-Based EF Migrations
- EF Migrations and a Merge Conflict
- Prevent EF Migrations from Creating or Changing the Database
- EF Code First Change Tracking
- EF Migrations Command Reference
- EF Code First Navigation Properties and Foreign Keys
- Update-Database MSI Custom Action
In my series exploring EF Migrations it is time to look into updates to tables. In this post I’ll make a simple update of a table by adding a column to it. Expanding on the example from the previous posts in this series a TopSpeed
column is added to the cars table. Before doing the actual update there’s another thing I want to change. When working in a team I don’t think that automatic migrations give control enough. Using them would cause the developers to end up with different migration order for their databases, yet another migration order for the user test environment and finally another migration order in the production environment. I think that it is better to be strict and use manual migrations. So first I’ll disable the automatic migrations that I enabled previously and then go on and add the new column.
public Configuration() { AutomaticMigrationsEnabled = false; } |
Now the new TopSpeed
column can be added.
public class Car { public int CarId { get; private set; } [ForeignKey("Car_Brand")] public Brand Brand { get; set; } [ForeignKey("Brand")] public int BrandId { get; private set; } [Required] [StringLength(6)] public string RegistrationNumber { get; set; } [Column("BodyStyle", TypeName="int")] public CarBodyStyle BodyStyle { get; set; } // Newly added property. public int? TopSpeed { get; set; } } |
A new migration is added form the package manager console. Without the automatic migrations a name is needed for the migration.
PM> add-migration Car_TopSpeed
Scaffolding migration 'Car_TopSpeed'.
The Designer Code for this migration file includes a snapshot of
your current Code First model. This snapshot is used to calculate
the changes to your model when you scaffold the next migration.
If you make additional changes to your model that you want to
include in this migration, then you can re-scaffold it by running
'Add-Migration 201202221302479_Car_TopSpeed' again. |
Looking in the Migrations folder of the project an new file is created called 201202221302479_Car_TopSpeed.cs (there is also an associated meta data file that I ignore for now).
namespace TestLib.Migrations { using System.Data.Entity.Migrations; public partial class Car_TopSpeed : DbMigration { public override void Up() { AddColumn("Cars", "TopSpeed", c => c.Int()); } public override void Down() { DropColumn("Cars", "TopSpeed"); } } } |
It looks straight forward. Both the Up()
and Down()
methods are generated correctly. To write the updates the update-database
command is used.
PM> update-database -verbose Using NuGet project 'TestLib'. Using StartUp project 'TestLib'. Target database is: 'Cars' (DataSource: ., Provider: System.Data.SqlClient, Origin: Configuration). Applying explicit migrations: [201202221302479_Car_TopSpeed]. Applying explicit migration: 201202221302479_Car_TopSpeed. ALTER TABLE [Cars] ADD [TopSpeed] [int] [Inserting migration history record] |
So far everything works fine. Tomorrow I will show a better way to add an index, that can be used when the table is created. Then I’ll go on with putting some stress on the system by simulating a merge conflict, where another developer has made changes to the Cars
table, at the same time as the TopSpeed
column was added.
1 comment