使用IdentityDbContext和Code First自动迁移表位置和架构的实体框架？

Question

I am trying to setup automatic migration updates using the IdentityDbContext class and propagating changes to the actual DbContext for the entire database.

Before I get into the code, on my implementation of the IdentityDbContext with automatic migrations I get this error:

Automatic migrations that affect the location of the migrations history system table (such as default schema changes) are not supported. Please use code-based migrations for operations that affect the location of the migrations history system table.

I am not going to post the models that are associated with the migrations and context code unless someone finds them of use.

Implemenation of the IdentityDbContext:

 public class SecurityContext: IdentityDbContext<User>
    {
        public SecurityContext() : base("MyActualContext")
        {

        }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {


            base.OnModelCreating(modelBuilder);

            //removing this line I do not get an error, but everything gets placed into the dbo schema. Keeping this line, i get the above error.
            modelBuilder.HasDefaultSchema("ft");
        }
    }

So I tried adding this class to place the migrations history into the correct schema. This, in fact, does move the migrations history into the correct schema, but everything else remains in the dbo schema.

public class MyHistoryContext : HistoryContext
    {
        public MyHistoryContext(DbConnection dbConnection, string defaultSchema)
            : base(dbConnection, defaultSchema)
        {
        }

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            base.OnModelCreating(modelBuilder);
            modelBuilder.HasDefaultSchema("ft");
        }
    }

public class SecurityContextMigrations : DbMigrationsConfiguration<SecurityContext>
    {
        public SecurityContextMigrations()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
            //When the migrations get set, I use the new class created to move the migrations to the correct schema.
            SetHistoryContextFactory("System.Data.SqlClient", (c, s) => new MyHistoryContext(c, s));
        }

        protected override void Seed(SecurityContext context)
        {
           ...
        }
    }

Ideally, I'd like everything to be in the ft schema. I don't think the migrations are that complex that I need to manually setup the migrations. I was hoping for simplicity sake, I could use automatic migrations for this. I am wondering if this approach is impossible and what I need to do to make this happen and any changes made to the models do get propagated.

Answer 1

I have a similar issue with Oracle 12c and EF6: I cannot get automatic migrations to work. I found, however, the following partial success factors: - I needed to set

modelBuilder.HasDefaultSchema("")

on my DbContext in order to get the runtime see the tables in the logon schema of the particular user - For the update-database it was necessary to set the MyHistoryContext parameters like that:

public class MyHistoryContext : HistoryContext
{
    public MyHistoryContext(DbConnection dbConnection, string defaultSchema)
        : base(dbConnection, defaultSchema)
    {
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
        modelBuilder.HasDefaultSchema("L2SRVRIZ");
    }
}

NOTE: You need to hard-code the schema name there. In this way, update-database does not try to use dbo as schema (but still no automatic migrations are possible, they will drop your MigrationHistory table and mess up everything). This is in my opinion a nasty bug inside either EF6 or the Oracle custom class. As I have no maintenance contract with them, I cannot file a ticket.

For your case, I think its not possible somehow by design to avoid the error message with automatic migrations. EF6 thinks, for some reason, that if you use a custom schema name, that you actually moving the __MigrationHistory table from the default dbo schema, which is of course not true.

Or, did you find a solution for that?

BR Florian