Updating a Table with EF Migrations

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; }
    public Brand Brand { get; set; }
    public int BrandId { get; private set; }
    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.

This post is part of the EF Migrations series.<< Adding Indexes with EF MigrationsIndexes in Code-Based EF Migrations >>

1 comment

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.