1

Yesterday I asked this question about changing the name of the __Migration History table generated by Entity Framework when using a Code First approach. The provided link was helpful in saying how to do what we want (and by "want" I mean what we're being forced into by our DBAs), however also left a somewhat non-specific and dire-sounding warning that says,

Words of precaution

Changing the migration history table is powerful but you need to be careful to not overdo it. EF runtime currently does not check whether the customized migrations history table is compatible with the runtime. If it is not your application may break at runtime or behave in unpredictable ways. This is even more important if you use multiple contexts per database in which case multiple contexts can use the same migration history table to store information about migrations.

We tried to use this warning to reason with the DBA team, telling them that we shouldn't mess with things because "here be dragons". Their response was, "It sounds more like the danger is in changing the content or the table structure, not the name. Go ahead and try it and see what happens."

Has anyone here changed the name of the __Migrations History table, and what was the result? Is it dangerous?

Community
  • 1
  • 1
J.D. Ray
  • 697
  • 1
  • 8
  • 22
  • Can you clarify what you mean by "it"? I'm clear that the `__Migration History` table works fine as generated by the system. I'm unclear whether or not changing the name creates instability in the system. – J.D. Ray Sep 24 '15 at 21:32
  • Your DBA team seems right. ***changing the content or the table structure*** could cause problem but not the name. So just go ahead and I like this ***see what happens***, meaning you have time and a chance to see it yourself (your DBA team now has took part in the responsibility of the whole project). – Hopeless Sep 25 '15 at 01:50
  • 1
    @J.D.Ray: changing the name just works. Tested multiple times in actual applications. – Wiktor Zychla Sep 25 '15 at 06:17

1 Answers1

3

Changing the name of the migrations history table is possible. But you have to tell EF this by calling the HasDefaultSchema method with the name of the schema in the OnModelCreating method of your DbContext class:

public partial class CustomerDatabasesModel : DbContext
{   
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.HasDefaultSchema("CustomerDatabases");

        // Fluent API configuration
    }   
}

This the will cause EF to create a "CustomerDatabases" prefix for all database tables. So in this example "CustomerDatabases" replaces the standard of "dbo" prefix of your tables. Your migration history table will be have the name CustomerDatabases.__MigrationHistory.

So in fact, you change the owner name of the database (the first part), the second part "__MigrationHistory" stays the same.


**Usage scenario:**

You usually do this, if you work with more than one DbContext. So you can have more than one MigrationHistory table in a single database, one for each context.

Of course you should carefully test this and perform database backups before.

Please check out this answer too: Entity-Framework: On Database, multiple DbContexts

Martin
  • 5,165
  • 1
  • 37
  • 50
  • 1
    It's not required to change Migration History table name for handle more than one model (context) in a single database. – bubi Sep 14 '16 at 12:59