Page 1 of 1
EF 4.3.1 always run all migrations on Update-Database
Posted: Thu 15 Mar 2012 21:26
by ciscoheat
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?
Posted: Fri 16 Mar 2012 11:17
by ciscoheat
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.
Posted: Fri 16 Mar 2012 14:04
by Shalex
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.
Posted: Fri 16 Mar 2012 14:58
by ciscoheat
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!
Posted: Fri 16 Mar 2012 15:21
by ciscoheat
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
}
}