DBContext overwrites previous migration

Question

I currently have two DbContexts, ApplicationDbContext and CompanyDBContext. However the problem is that when I run my MVC web application only the CompanyDBContext gets reflected on the database and I see none of the implementation made in ApplicationDbContext being shown in the database. Both my contexts use the same connection string. The ApplicationDbContext was auto-generated when I created my MVC application as I had selected Individual accounts

Currently the ApplicationDbContext looks like this

 public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
 {
    public ApplicationDbContext()
        : base("DevConnection", throwIfV1Schema: false)
    {
    }

    public static ApplicationDbContext Create()
    {
        return new ApplicationDbContext();
    }

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        modelBuilder.Ignore<CompanyDetails>();
    }
}

and here is my CompanyDbContext

public class CompanyDBContext : DbContext
{

    public CompanyDBContext() : base("DevConnection")
    {
    }

    public DbSet<CompanyDetails> companies { get; set; }

}

Maybe http://www.codeproject.com/Tips/801628/Code-First-Migration-in-Multiple-DbContext would help? — jjj, May 15 '15 at 22:36
So for each migration there will be a new configuration file specifically for that specific context? — Johnathon64, May 15 '15 at 22:41

score 2 · Answer 1 · answered May 16 '15 at 04:09

I would delete the migrations you have now if you dont need them then use the command below to enable them separately by specifying their names and directories, so they are created separately.

enable-migrations -ContextTypeName MyCoolContext -MigrationsDirectory MyCoolMigrations

http://www.mortenanderson.net/code-first-migrations-for-entity-framework

score 1 · Answer 2 · answered May 15 '15 at 22:23

1

It's seems like only one dbContext can be updated at a moment. You must Enable-Migration , Add-Migration and Update-Database for each dbContext. This is the way i do it. But my dbContext were in different projects, so may be it can be the same for you! Update separately didn't overwrite my database. It works for me !

answered May 15 '15 at 22:23

Tchaps

865
7
21

thanks for the input, I have tried this, however because they are in the same project I cannot enable migration for that single dbContext. When I try to it says that migrations are already enabled. I have tried putting the -Force command in but to no avail this did not work either – Johnathon64 May 15 '15 at 22:29
I think I may have been typing the commands wrong. I'll give it a go tomorrow and if it works I'll give you a tick. – Johnathon64 May 15 '15 at 22:42

score 1 · Accepted Answer · edited May 23 '17 at 11:51

1

I was curious, so I looked around, and it seems like the solution for migrations and multiple DbContexts is to have a single DbContext that serves as a complete representation of the database through which initialization and migration is handled, and disable database initialization in the constructor of all other DbContext classes.

You could do this through a combination of Database.SetInitializer and an explicit call to DbContext.Database.Initialize()

Sources

edited May 23 '17 at 11:51

Community

1
1

answered May 15 '15 at 23:05

jjj

4,822
1
16
39

Do you need to have all the dbsets in each and every context within that one single context? Like this http://stackoverflow.com/questions/17246069/multiple-dbcontexts-on-one-db-with-code-first-migrations – Johnathon64 May 16 '15 at 10:06
Yea, because that one main context will basically serve as the database definition, and your database will be created and migrated using that. – jjj May 16 '15 at 17:46
but wouldn't that mean there won't be much point in the other dbContexts? Sorry I'm just trying to understand a need since the context that handles migrations does pretty much everything. – Johnathon64 May 17 '15 at 18:43
The second link includes motivation for why someone might have multiple contexts: "small models that target supporting specific operations". If your application is small, there might be no reason to have multiple. – jjj May 18 '15 at 00:32

score 0 · Answer 4 · answered Aug 26 '15 at 15:06

In think the problem you have, it that your database tables / migrations are not separated.

In EF6 if you work with more than one context, I recommend to specify the name for the default schema in the OnModelCreating method of you DbContext derived class (where the Fluent-API configuration is).

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

        // Fluent API configuration
    }   
}

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

        // Fluent API configuration
    }   
}

This example will use "Application" and "Company" as prefixes for your database tables (instead of "dbo") in your (single) database. More importantly it will also prefix the __MigrationHistory table(s), e.g. Application.__MigrationHistory and Company.__MigrationHistory. So you can have more than one __MigrationHistory table in a single database, one for each context. So the changes you make for one context will not mess with the other.

When adding the migration, specify the fully qualified name of your configuration class (derived from DbMigrationsConfiguration) as parameter in the add-migration command:

add-migration NAME_OF_MIGRATION -ConfigurationTypeName FULLY_QUALIFIED_NAME_OF_CONFIGURATION_CLASS

e.g.

add-migration NAME_OF_MIGRATION -ConfigurationTypeName ApplicationConfiguration

if ApplicationConfiguration is the name of your configuration class.

In such a scenario you might also want to work with different "Migration" folders in you project. You can set up your DbMigrationsConfiguration derived class accordingly using the MigrationsDirectory property:

internal sealed class ApplicationConfiguration: DbMigrationsConfiguration<ApplicationDbContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = false;
        MigrationsDirectory = @"Migrations\Application";
    }
}

internal sealed class CompanyConfiguration : DbMigrationsConfiguration<CompanyDBContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = false;
        MigrationsDirectory = @"Migrations\Company";
    }
}

DBContext overwrites previous migration

4 Answers4