Use several Code First Data Contexts and several (different) Migrations in one database
Say there is one database shared by several applications, objects are separated by schema. So it would be nice to be able to store and apply migrations for one schema independently from another one.
When we originally marked this issue as completed we did not take into consideration the ability to ignore certain tables in migrations for overlapping models.
This is still not supported in EF Core (or in EF6)
Gordon Rudman commented
Thanks for taking my suggestion
Richard Beier commented
This would be useful for us. We have two systems which use different schemas in the same DB: a legacy system, and a new system that uses the legacy system. The new system is using EF code-first with migrations. We sometimes need to make modifications to the legacy system's schema... it would be nice to use migrations for that too.
Maybe it will work if we have two separate assemblies, one for new-system migrations and one for legacy migrations. But if the migrations are all tracked in the same __MigrationHistory table, I guess it's not currently possible to independently roll back or roll forward the changes to each schema.
Migration would be easier if we just used separate databases for the two systems. But that would increase the maintenance overhead, and I don't think our DBA would like it.
Cyril DURAND commented
For information, my real situation is quite different, I need to manage multi-tenancy.
For that, I create one DbCompiledModel per tenancy, when my application need a DbContext instance, I instanciate it with the correct cached DbCompiledModel. I isolate each DbCompiledModel by using a different database schema.
I started with an existing database. created an mvc app (app1) with couple of models. I then created a schema for this app in database. I specified schema for the models as per your comment. Then I used the power of code based migration script to update the database. Migration script created 2 tables under the new schema without corrupting existing stuff. I noticed EF created __MigrationHistory table with a row with change info. Then i created another app, a new schema and repeated the migration process with a little tweak in migration script. The script had code to re-create 2 tables of app1. i deleted that code from script. EF then successfully created new tables under new schema and also created new row in __MigrationHistory table with info about new changes. All existing stuff remain unchanged including data.
romero: add a new connection in your web.config, create a new class derived from dbcontext in you model(use your contextdb as "template"), uhmm... add your sets... you may want to override some methods too... like creatingmodel just to mention one.
David Egli commented
I'm implmenting an extensible CMS, the extensions reside in custom assemblies, that must access the DB with their own Contexts. So what I need is to be able to access the DB with multiple contexts. Currently I've implemented a table that stores a per Context copy of the dbo.__MigrationHistory table, and each time a Migration should take place, is copied back.
But I didn't get it to work yet, in the package manager console Add-Migration is always crashing, no clue why, maybe because I have multiple Contexts in an assembly.
All that is needed is another 'ApplicationId' column like in ASP.Net memberships, simple !
Or use separate db schemas per Application / DB Context.
Setting a default schema name should actually be a lot simpler than it currently is.
This would be great for hosting websites at places like GoDaddy, where you just have to make do with 1 or 2 MS SQL databases.
Without it you cannot use Code-first for more than 1 website. :-(
How to initialize multiple dbcontexts in a unique database?