Post
Ask Question

Avoid Nightmares Using EF First Migration in Azure Mobile Services

Scope

The purpose of this article is to show how to enable, add and use Entity Framework Code First Migrations in Azure Mobile Services to create and update the database based in the model.

Introduction

Microsoft Azure Mobile Services is an Azure service offering designed to make it easy to create highly-functional mobile apps using Azure. Mobile Services brings together a set of Azure services that enable backend capabilities for your apps.

In Azure Mobile Services, there are multiple ways to create the database, it can be created manually in SQL Server Management Studio or in Visual Studio, or can be created using Code First Migrations or using IDatabaseInitializer. By default, Azure Mobile Service uses database initializers, like as can be seen in the following WebApiConfig class from the project created:

  1. namespace AzureMobileService  
  2. {  
  3.     public static class WebApiConfig  
  4.     {  
  5.         public static void Register()  
  6.         {  
  7.             // Use this class to set configuration options for your mobile service  
  8.             ConfigOptions options = new ConfigOptions();  
  9.    
  10.             // Use this class to set WebAPI configuration options  
  11.             HttpConfiguration config = ServiceConfig.Initialize(new ConfigBuilder(options));  
  12.    
  13.             // To display errors in the browser during development, uncomment the following  
  14.             // line. Comment it out again when you deploy your service for production use.  
  15.             // config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;  
  16.    
  17.             Database.SetInitializer(new MobileServiceInitializer());  
  18.         }  
  19.     }  
  20.    
  21.     public class MobileServiceInitializer : DropCreateDatabaseIfModelChanges<MobileServiceContext>  
  22.     {  
  23.         protected override void Seed(MobileServiceContext context)  
  24.         {  
  25.             List<TodoItem> todoItems = new List<TodoItem>  
  26.             {  
  27.                 new TodoItem { Id = Guid.NewGuid().ToString(), Text = "First item", Complete = false },  
  28.                 new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Second item", Complete = false },  
  29.             };  
  30.    
  31.             foreach (TodoItem todoItem in todoItems)  
  32.             {  
  33.                 context.Set<TodoItem>().Add(todoItem);  
  34.             }  
  35.    
  36.             base.Seed(context);  
  37.         }  
  38.     }  
  39. }  
Like we can see, the MobileServiceInitializer implements the DropCreateDatabaseIfModelChanges, it is an implementation of IDatabaseInitializer that will DELETE, recreate and optionally re-seed the database only if the model has changed, since the database was created. If the model doesn't change we can use it, but “Are we sure that the model will not change in future?” this way maybe this solution is not a best solution to create the database.

Note: There are others IDatabaseInitializer that can be used, but the problem is the same, data will be lost if the model changes.

In this article we will use Entity Framework - Code First Migrations, that means we create the model first and then create the database based in the model structure, this process happens when we do a deploy and we will see common issues related with migrations in Azure Mobile Services.

Description

Create a .Net Backend as in the following:

Creating an Azure Mobile Service
Figure 1 Creating an Azure Mobile Service

Then create a class diagram as in Figure 2, to understand the project.

Note: Read more about creating the class diagram in the article Class diagram: an easy way to understand code.

The class diagram
Figure 2 The class diagram

This way, we can conclude, by default an Azure Mobile Service has at least the following classes:

 

  • TodoItem: define the model and at the same time the DTO

  • MobileServiceContext: implement the DbContext from the Entity Framework

  • TodoItemController: define the service to expose CRUD operation to the TodoItem

And the model defined by TodoItem is the DTO provided by the service defined in the TodoItemController.

Notes:

  1. We could create another model but it is not important for the article, this way we will use the model provided by default.

  2. TodoItem implements the EntityData from the Azure Mobile Service SDK and each DTO should implement this class because it is necessary to use the offline feature provided by Azure Mobile Services and to create a TableController we need it.

Enable Migrations

At this moment we understand the model and the DbContext, but before starting with the migrations process we need to define the connection string to a New database in WebConfig. Now we need to enable the project to have migrations, for that open the “Package Manager Console” as in the following:

Opening Package Manager Console
Figure 3 Opening Package Manager Console

The following window will be opened:

Package Manager Console
Figure 4 Package Manager Console

To enable migration it is necessary to run “Enable-Migrations” in the “Package Manager Console” and the “Default project” should be selected based on the project that contains the DbContext:

Enable Migrations
Figure 5 Enable Migrations

This operation will result in a new folder, called Migrations with a new class, in the project, like we can see in the Figure 6.

Migrations folder
Figure 6 Migrations folder

The class added, the Configuration, is defined by:

  1. internal sealed class Configuration : DbMigrationsConfiguration<Models.MobileServiceContext>  
  2. {  
  3.     public Configuration()  
  4.     {  
  5.         AutomaticMigrationsEnabled = false;  
  6.     }  
  7.   
  8.     protected override void Seed(AzureMobileService.Models.MobileServiceContext context)  
  9.     {  
  10.         //  This method will be called after migrating to the latest version.  
  11.   
  12.         //  You can use the DbSet<T>.AddOrUpdate() helper extension method   
  13.         //  to avoid creating duplicate seed data. E.g.  
  14.         //  
  15.         //    context.People.AddOrUpdate(  
  16.         //      p => p.FullName,  
  17.         //      new Person { FullName = "Andrew Peters" },  
  18.         //      new Person { FullName = "Brice Lambson" },  
  19.         //      new Person { FullName = "Rowan Miller" }  
  20.         //    );  
  21.         //  
  22.     }  
  23. }  
And this class will be responsible for creating, updating or deleting the database depending on the migration provided and it is possible to populate the database with the initial data using the seed method. The seed method can be used to create fake data or add initial data to the database and all developers should be aware that the method can run more than one time, with it it is necessary to verifiy that the data is not cloned.

Let's define some data in the Seed method, as in the following:
  1. internal sealed class Configuration : DbMigrationsConfiguration<Models.MobileServiceContext>  
  2. {  
  3.     /// <summary>  
  4.     /// Initializes a new instance of the <see cref="Configuration"/> class.  
  5.     /// </summary>  
  6.     public Configuration()  
  7.     {  
  8.         AutomaticMigrationsEnabled = false;  
  9.     }  
  10.   
  11.     /// <summary>  
  12.     /// Seeds the specified context.  
  13.     /// </summary>  
  14.     /// <param name="context">The context.</param>  
  15.     protected override void Seed(Models.MobileServiceContext context)  
  16.     {  
  17.         context.TodoItems.AddOrUpdate(  
  18.               p => p.Id,  
  19.               new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Clean the car." },  
  20.               new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Read a book" }  
  21.             );  
  22.     }  
  23. }  
Add Migration

Before adding the migration all developers should be aware that in the MobileServiceContext class we have the method.
  1. protected override void OnModelCreating(DbModelBuilder modelBuilder)  
  2. {  
  3.     string schema = ServiceSettingsDictionary.GetSchemaName();  
  4.     if (!string.IsNullOrEmpty(schema))  
  5.     {  
  6.         modelBuilder.HasDefaultSchema(schema);  
  7.     }  
  8.   
  9.     modelBuilder.Conventions.Add(  
  10.         new AttributeToColumnAnnotationConvention<TableColumnAttribute, string>(  
  11.             "ServiceTableColumn", (property, attributes) => attributes.Single().ColumnType.ToString()));  
  12. }  
And in this method will be defined the name of the schema used by the database and the name of the schema is defined in the WebConfig file, as in the following:
  1. <appSettings>  
  2. <add key="MS_MobileServiceName" value="migrations" />  
Where the value “migrations” is the name of the Azure Mobile Service, if the schema name and the Azure Mobile Service's name does not match the migration, it will fail because of the default user, used by the Azure Mobile Service created, do not have permissions to change the schema name or is possible to get an error saying that the user do not have permission to access the master database.

We can then add the migration and for that we need to run “Add-Migration Initial” in “Package Manager Console”, this command will use the model defined in the project and will compare it with the database, to create the migration.

Adding migration Initial
Figure 7 Adding migration Initial

The result will be something as in the following:

The migration
Figure 8 The migration

The Initial class will define the migration and the Up method to create the database and the table “AzureMobileService.TodoItems” and the Down method will do the reverse. The Initial class will be defined by:
  1. public partial class Initial : DbMigration  
  2. {  
  3.     public override void Up()  
  4.     {  
  5.         CreateTable(  
  6.             "migrations.TodoItems",  
  7.             c => new  
  8.                 {  
  9.                     Id = c.String(nullable: false, maxLength: 128,  
  10.                         annotations: new Dictionary<string, AnnotationValues>  
  11.                         {  
  12.                             {   
  13.                                 "ServiceTableColumn",  
  14.                                 new AnnotationValues(oldValue: null, newValue: "Id")  
  15.                             },  
  16.                         }),  
  17.                     Text = c.String(),  
  18.                     Complete = c.Boolean(nullable: false),  
  19.                     Version = c.Binary(nullable: false, fixedLength: true, timestamp: true, storeType: "rowversion",  
  20.                         annotations: new Dictionary<string, AnnotationValues>  
  21.                         {  
  22.                             {   
  23.                                 "ServiceTableColumn",  
  24.                                 new AnnotationValues(oldValue: null, newValue: "Version")  
  25.                             },  
  26.                         }),  
  27.                     CreatedAt = c.DateTimeOffset(nullable: false, precision: 7,  
  28.                         annotations: new Dictionary<string, AnnotationValues>  
  29.                         {  
  30.                             {   
  31.                                 "ServiceTableColumn",  
  32.                                 new AnnotationValues(oldValue: null, newValue: "CreatedAt")  
  33.                             },  
  34.                         }),  
  35.                     UpdatedAt = c.DateTimeOffset(precision: 7,  
  36.                         annotations: new Dictionary<string, AnnotationValues>  
  37.                         {  
  38.                             {   
  39.                                 "ServiceTableColumn",  
  40.                                 new AnnotationValues(oldValue: null, newValue: "UpdatedAt")  
  41.                             },  
  42.                         }),  
  43.                     Deleted = c.Boolean(nullable: false,  
  44.                         annotations: new Dictionary<string, AnnotationValues>  
  45.                         {  
  46.                             {   
  47.                                 "ServiceTableColumn",  
  48.                                 new AnnotationValues(oldValue: null, newValue: "Deleted")  
  49.                             },  
  50.                         }),  
  51.                 })  
  52.             .PrimaryKey(t => t.Id)  
  53.             .Index(t => t.CreatedAt, clustered: true);  
  54.           
  55.     }  
  56.       
  57.     public override void Down()  
  58.     {  
  59.         DropIndex("migrations.TodoItems", new[] { "CreatedAt" });  
  60.         DropTable("migrations.TodoItems",  
  61.             removedColumnAnnotations: new Dictionary<string, IDictionary<string, object>>  
  62.             {  
  63.                 {  
  64.                     "CreatedAt",  
  65.                     new Dictionary<string, object>  
  66.                     {  
  67.                         { "ServiceTableColumn", "CreatedAt" },  
  68.                     }  
  69.                 },  
  70.                 {  
  71.                     "Deleted",  
  72.                     new Dictionary<string, object>  
  73.                     {  
  74.                         { "ServiceTableColumn", "Deleted" },  
  75.                     }  
  76.                 },  
  77.                 {  
  78.                     "Id",  
  79.                     new Dictionary<string, object>  
  80.                     {  
  81.                         { "ServiceTableColumn", "Id" },  
  82.                     }  
  83.                 },  
  84.                 {  
  85.                     "UpdatedAt",  
  86.                     new Dictionary<string, object>  
  87.                     {  
  88.                         { "ServiceTableColumn", "UpdatedAt" },  
  89.                     }  
  90.                 },  
  91.                 {  
  92.                     "Version",  
  93.                     new Dictionary<string, object>  
  94.                     {  
  95.                         { "ServiceTableColumn", "Version" },  
  96.                     }  
  97.                 },  
  98.             });  
  99.     }  
  100. }   
Run the migration

Now that we have the migration defined we can run the project but the database will not be created, because we did not define how the project will run the migration or we do not update the database using “Update-Database” or “Update-Database -script” as we can see in Figure 9.

Creating the sql script
Figure 9 Creating the SQL script

This operation will create a SQL script that can be used to create or even update the database if the developer would like.

In Azure Mobile Services, we use.
  1. var migrator = new DbMigrator(new Configuration());  
  2. migrator.Update();  
To run the migration that will be defined in WebApiConfig.

To avoid the issue about “Not found bootstrapper”, we need to change the WebApiConfig to:
  1. public class WebApiConfig : IBootstrapper  
  2. {  
  3.     /// <summary>  
  4.     /// Defines the entry point for the application. It is the responsibility of this entry point  
  5.     /// to call <see cref="T:Microsoft.WindowsAzure.Mobile.Service.ServiceConfig" /> which will start the configuration of the application.  
  6.     /// </summary>  
  7.     public void Initialize()  
  8.     {  
  9.         // Use this class to set configuration options for your mobile service  
  10.         ConfigOptions options = new ConfigOptions();  
  11.   
  12.         // Use this class to set WebAPI configuration options  
  13.         HttpConfiguration config = ServiceConfig.Initialize(new ConfigBuilder(options));  
  14.   
  15.         // To display errors in the browser during development, uncomment the following  
  16.         // line. Comment it out again when you deploy your service for production use.  
  17.         config.IncludeErrorDetailPolicy = IncludeErrorDetailPolicy.Always;  
  18.   
  19.         var migrator = new DbMigrator(new Configuration());  
  20.         migrator.Update();  
  21.     }  
  22. }  
And then we need to change the WebApiApplication, as in the following:
  1. public class WebApiApplication : System.Web.HttpApplication  
  2. {  
  3.     /// <summary>  
  4.     /// The _web API configuration  
  5.     /// </summary>  
  6.     private readonly WebApiConfig _webApiConfig;  
  7.   
  8.     /// <summary>  
  9.     /// Initializes a new instance of the <see cref="WebApiApplication"/> class.  
  10.     /// </summary>  
  11.     public WebApiApplication()  
  12.     {  
  13.         _webApiConfig = new WebApiConfig();  
  14.     }  
  15.   
  16.     /// <summary>  
  17.     /// Application_s the start.  
  18.     /// </summary>  
  19.     protected void Application_Start()  
  20.     {  
  21.         _webApiConfig.Initialize();  
  22.     }  
  23. }  
Each developer should be aware that when the Initialize method is run, each time the application starts, it will create or update the database based in the migrations defined by the current model.

Publishing the services:

publishing the service
Figure 10 publishing the service

It is possible to use the following publishing process using the “Web Publish Activity”, as we can see in Figure 11.

Web Publish Activity
Figure 11 Web Publish Activity

Note: When we do the publish the Azure Mobile Service will replace some configuration from WebConfig, if you want to see the final WebConfig see this article.

The browser will be opened, as in the following:

Azure Mobile Service running
Figure 12 Azure Mobile Service running

And we can request the TodoItems in “try this out”, like we can see in the Figure 13.

Try it out
Figure 13 Try it out

Or in the database:

Data in database
Figure 14 Data in database

Log
Figure 15 Log

Handle errors

Changing the model

The backend can change and with it the model can change. If we change the model without creating the respective migration we will receive an error like this.

Error:

Boot strapping failed: executing 'WebApiConfig' caused an exception: 'Unable to update database to match the current model because there are pending changes and automatic migration is disabled. Either write the pending model changes to a code-based migration or enable automatic migration. Set DbMigrationsConfiguration.AutomaticMigrationsEnabled to true to enable automatic migration.”

Azure Mobile Service with errors
Figure 16 Azure Mobile Service with errors

Let's change the model to something as in the following:
  1. public class TodoItem : EntityData  
  2. {  
  3.     public string Text { get; set; }  
  4.   
  5.     public string Name { get; set; }  
  6.   
  7.     public bool Complete { get; set; }  
  8. }  
Then we need to add a new migration, for that we need to run “Add-Migration SecondMigration” in “Package Manager Console”, as in the following:

PM> add-migration SecondMigration
Scaffolding migration 'SecondMigration'.

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 SecondMigration' again.
PM>

And the result will be:
  1. public partial class SecondMigration : DbMigration  
  2. {  
  3.     public override void Up()  
  4.     {  
  5.         AddColumn("migrations.TodoItems", "Name", c => c.String());  
  6.         DropColumn("migrations.TodoItems", "DueDate");  
  7.     }  
  8.       
  9.     public override void Down()  
  10.     {  
  11.         AddColumn("migrations.TodoItems", "DueDate", c => c.DateTime(nullable: false));  
  12.         DropColumn("migrations.TodoItems", "Name");  
  13.     }  
  14. }  
If we change the seed method to:
  1. protected override void Seed(Models.MobileServiceContext context)  
  2. {  
  3.     context.TodoItems.AddOrUpdate(  
  4.           p => p.Id,  
  5.           new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Clean the car.", Name = "MyTask"},  
  6.           new TodoItem { Id = Guid.NewGuid().ToString(), Text = "Read a book", Name = "MyHobbies" }  
  7.         );  
  8. }  
After that we can publish the Azure Mobile Service and the result will be:

Try this out
Figure 17 Try this out

And:

migration

Developers should be aware that the seed method added new items that has the same “Text” as the first items added but in this case the “Name” is filled. This was a sample from a common issue we can create when populating data during multiple migrations.

Note: If the connecting string, defined in WebConfig, is not using the correct reference, this process can fail with the following error.

PM> add-migration SecondMigration

Unable to generate an explicit migration because the following explicit migrations are pending: [201501162340213_Initial]. Apply the pending explicit migrations before attempting to generate a new explicit migration.
PM>

Deleting the Database

If during the process, we delete the database and then we try to run the services we will get:

Deleting the Database

log entry detail

This way, the default user, used by the Azure Mobile Service created, does not have permissions to access the master database.

The errors we got with the default user are related to the fact the user only has a few permissions for security reasons. Creating a database user will avoid this kind of issue.

Conclusion

In conclusion, we can conclude that EF CodeFirst Migration is a good way to manage the various changes made in the model and this way any time an Azure Mobile Service is deployed it will create or update the associated database without additional work, with initial data or not.

If we are using the default user to access the database:

 

    - the user cannot access the master to re-create the database.

    - the database schema must have the same name as the Azure Mobile Service.

If we create a database user to avoid the two last problems, you need to ignore the default connection string (MS_TableConnectionString) and you need to create your own connection string (for example: MyTableConnectionString where you need to define all required fields to the database and should be added the user created to avoid the issues).

Personal opinion + Disclaimer:

I have lost so much time from this problem and in the end I prefer to create and use my own database user to simplify the process and define my own key to the connection string (that can be defined in the configuration panel). In my experience the user is changed time to time and it happened to me more than one time. Never found it in the documentation.

Source Code

See the source code in Azure Mobile Services Sample.

See Also


Similar Articles