EF 4.3.1 always run all migrations on Update-Database

Discussion of open issues, suggestions and bugs regarding Entity Framework support in ADO.NET Data providers
Post Reply
ciscoheat
Posts: 4
Joined: Thu 15 Mar 2012 20:08

EF 4.3.1 always run all migrations on Update-Database

Post by ciscoheat » Thu 15 Mar 2012 21:26

I have created an initial migration with Add-Migration. When I run Update-Database on an empty DB it creates all tables, including adding an entry in the __MigrationHistory table.

Now I run Update-Database again just to test, and instead of "No changes detected" I get this:

Code: Select all

PM> Update-Database -Verbose -Project testProject.Web
Using StartUp project 'testProject.Web'.
Target database is: 'testProject_dbo' (DataSource: localhost, Provider: Devart.Data.MySql, Origin: Explicit).
Applying explicit migrations: [201203151243164_Start].
Applying explicit migration: 201203151243164_Start.
CREATE TABLE attachments ( 
 ...table data...
)
Table 'attachments' already exists
Table 'attachments' already exists
It seems like the update is unaware of the current DB state. The only solution is to delete all tables and update. That works also if I add more migrations.

I have followed the instructions in the blog post and everything works up to this point, so I'm not sure if the problem is in EF or the MySql connector. Any ideas?

ciscoheat
Posts: 4
Joined: Thu 15 Mar 2012 20:08

Post by ciscoheat » Fri 16 Mar 2012 11:17

More tests reveal that using the default provider (connecting to .\SQLEXPRESS) works, as it gives me the message "No pending explicit migrations." if I execute Update-Database more than once.

Shalex
Site Admin
Posts: 8245
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Fri 16 Mar 2012 14:04

The most probable reason is that you are putting the IgnoreSchemaName workaround in an inappropriate place. We recommend you to set it in a static constructor of your DbContext-descendant or in any other place where it would be called even when using Package Manager Console. Refer to http://www.devart.com/blogs/dotconnect/ ... qlite.html.

Package Manager Console compiles a project (but doen't run it) and uses only DbContext-descendant.

The DatabaseExists check applies full mapping of the model, but Code-First Migrations uses only mapping which is defined in migrations.

ciscoheat
Posts: 4
Joined: Thu 15 Mar 2012 20:08

Post by ciscoheat » Fri 16 Mar 2012 14:58

Yes, that was exactly the reason! I called the workaround in the DI configuration in my auto-migration setup, but not in the class that was instantiated when executing Update-Database from the console. Thank you!

ciscoheat
Posts: 4
Joined: Thu 15 Mar 2012 20:08

Post by ciscoheat » Fri 16 Mar 2012 15:21

Here is the class that was the result of my endeavors:

Code: Select all

internal sealed class Configuration : DbMigrationsConfiguration
{
    public Configuration()
    {
        // Because the Package Manager Console (NuGet) instantiates YourDbContext with the empty constructor,
        // a custom connection must be specified. Based on http://www.devart.com/blogs/dotconnect/?p=5603
        // Note that the MySqlProviderFactory must also be present in Web.config or App.config in the *startup project*
        // for this to work! Configuration example:

        /*
          
            
              
              
              
            
          
        */

        // Apply the IgnoreSchemaName workaround
        MySqlEntityProviderConfig.Instance.Workarounds.IgnoreSchemaName = true;

        // Create a custom connection to specify the database and set a SQL generator for MySql.
        var connectionInfo = MySqlConnectionInfo.CreateConnection("");

        TargetDatabase = connectionInfo;
        SetSqlGenerator(connectionInfo.GetInvariantName(), new MySqlEntityMigrationSqlGenerator());

        // Enable automatic migrations if you like
        AutomaticMigrationsEnabled = false;

        // NuGet also had some problem with referencing EntityFramework 4.3.1.0 for me, so another fix that needs
        // to be applied in Web.config is this:

        /*
          
              
              
                
                
              
            
          
        */

        // After these Web.config additions, running migrations in Package Manager Console should be as easy as:
        // Update-Database -Verbose -ProjectName Your.MigrationsProject

        // Creating new migrations:
        // Add-Migration -Name MigrationDescription -ProjectName Your.MigrationsProject
    }
}

Post Reply