CODEWITHSUNDEEP
c#entity-frameworkasp.net-mvc-5
Johnathon64
Johnathon64

Reputation: 1320

DBContext overwrites previous migration

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; }

}

Upvotes: 2

Views: 442

Answers (4)

Martin
Martin

Reputation: 5623

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";
    }
}

Upvotes: 0

imGreg
imGreg

Reputation: 900

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

Upvotes: 2

jjj
jjj

Reputation: 4997

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

Upvotes: 1

Tchaps
Tchaps

Reputation: 874

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 !

Upvotes: 1

Related Questions