We have a huge database with different database schemas for different web applications.
For example: WebApp1 uses Schema1.Tables. WebApp2 uses Schema2.Tables and so on.
Now, I am developing a new web application (WepApp3) which will use Entity Framework 4.3.1. WebApp3 should only be concerned with Schema3 and use only those database object which are part of Schema3. If i create some Entities in WepApp3, How do i migrate these entities to database as schema3.tables? Do i still need to do Initial Migration?
Please help.
I don't think it's possible to have multiple EF models in the same database. EF shouldn't try to touch tables that are nothing to do with its model, but if you wanted to add another EF app to the same database you'd run into trouble because they'd try to share the same MetaData tables.
When generating new models using code-first, you can specify which schema they should be part in the DbContext:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<MyEntity>().ToTable("MyEntity", "Schema3");
}
Is it an option to migrate your schemas out into different databases if there are no shared apps?
It seems to WORK. 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.
Related
I have a .NET Core 5 application with Entity Framework (code first) with migrations and Azure SQL database.
I want to run two separate applications on same DB with different data. I want to have test and demo application. My idea was to change schema for each application. One application will have schema "test." and another one "demo.".
I tried to do this with this article
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.HasDefaultSchema("demo");
}
Problem is that I need to run Add-Migration with this approach. And I don't want to do that.
There is also another way that I didn't try. Described here
Problem there is that I need to create EntityConfiguration for each Entity and I don't want to do this neither.
I want to set schema globally for all tables at once.
Is there a way how to do this without creating new migrations? Or is there a better way without changing scheme?
I am stuck trying to figure out how to set the database to run a migration on.
I have created a new empty project and set up Entity Framework using code first. I have all my classes built.
I want to add a new database and run the migrations on this. I have Migrations working but I can't figure out what database they are running on.
Is it possible to set the database you want to use for the migrations?
Multiple DBs for the same context gets a little tricky. But It is possible:
The essence of the problem is how EF decides which connection to use.
It will access instantiate the context without NO PARAMS during migration.
So depending on how that behaves influences you outcome and success.
Start here:
EntityFramework code-first custom connection string and migrations
I am developing an EF - MVC 3 application. I have used model first approach, so I have create model first and from that model, EF generated the DB.
I have used a tool called Nuget - Entity Generator - Database designer for generating the database. When I have designed the model first time, I have used the Generate Migration T-SQL and Deploy option of that tool.
Database generated perfectly and it's working fine...
Now I have come across a situation that I have to make a change to the model and I have to use T-SQL Via T4 (TPH) option to update the database.
So previously I used different process to update DB and now I am changing it.
When I use the T-SQL Via T4 (TPH) all the tables get deleted and new tables get created.
How to avoid this ?
I want to only update the table which I have made the changes.
Entity framework 4.3 comes with migration support. This is not available in EF 4.1.
Some links from google:
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx
http://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-code-based-migrations-walkthrough.aspx
The scenario I'm having problems with is as follows:
Code First model created using EF 4.1 and corresponding database generated
EF upgraded to 4.3.1 and a migration added (using IgnoreChanges because no model changes) to start using migrations (__MigrtionHistory table created and EdmMetadata dropped) - let's call it 'InitialMigration'
Model is changed, say a new property is added and a migration that adds a corresponding column is generated (let's call this one 'NewPropertyMigration') and then applied to a Dev database (using our version of Migrate To Latest initialization strategy)
When code is promoted to production the database there is updated with new column as expected
Then when a brand new database is created in Dev and because it is based on latest model it will include the new column right after it is created but when the initialization strategy is run it still finds 'InitialMigration' and 'NewPropertyMigration' as pending but they both fail because EdmMetadata is not there so nothing to be removed and new column is already there so can't add
When I check __MigrationHistory table on this new database it only contains 'InitialCreate' entry so that would explain why the other two migrations are considered as pending. But I can't see how they would ever get into this table without being applied and at the same time they don't really need to be applied because database already contains any changes they cover.
What am I missing?
I'll just add that it seems a bit suspicious that the Model column in 'InitialCreate' is different to the one in 'NewPropertyMigration' even though they represent the same model. Could that be the cause?
Update:
This is the code I use to create new database and apply any migrations automatically at the same time
public class MigratePaymentsToLatestVersion<TContext> : IDatabaseInitializer<TContext> where TContext : DbContext
{
public void InitializeDatabase(TContext context)
{
// Create a brand new database if it doesn't exist but still apply any pending migrations
context.Database.CreateIfNotExists();
var migrator = new DbMigrator(configuration);
migrator.Update();
}
}
Update 2: Simpler scenario showing the same problem
While investigating this further I've been able to reproduce the behaviour in a much simpler scenario described below:
Create simple model and context
In a test application add one entity - with all default settings database is automatically created and object added
Enable migrations - 'InitialCreate' migration is generated
Update-Database - command returns no pending migrations because 'InitialCreation' is already in __MigrationHistory
Delete database and re-run test application - database is re-created automatically again
At this point I can't add any additional migrations or run update-database because 'InitialCreation' migration is seen as pending but cannot be applied because all entities already exist
I have it sorted now. The crucial bit I was missing seems to be related to the way you move from 4.1 to 4.3. I have been following steps from ef-4-3-migrations-and-existing-database. What seems to work better is the procedure described in the SO question how-to-use-migrations-on-an-existing-db.
If you compare both of them you'll see that one relies on -IgnoreChanges when you do first migration (called 'InitialMigration') while the other one creates a full 'InitialCreate' migration that contains your entire model at that point in time. Two important consequences of the latter approach are:
- when creating a brand new database InitialCreate migration, which contains full definition of the model, is used to create database instead of 'the other code' (not sure exactly but guessing that this is the part that is needed when migrations are not enabled) that generates database based on the model
- new database is created with up-to-date model and with all migrations listed in __MigrationHistory
So with the InitialCreate approach I am able to apply migrations to existing databases (for them the InitialCreate is simply skipped because an entry in history is added manually as part of the procedure) and at the same time I am able to create brand new databases and add new migrations to them without getting an error that model and db are out-of-sync.
I hope that helps people who, like me, followed the first procedure.
I see that EF can update a model based on an existing database schema. However, I'm starting totally from scratch; I don't want to build tables, then rebuild them in the EF model file. Is there a way that I can draw out a model file, and have the SQL tables automatically be created for me?
Unfortunately, you have to wait for version 2 of EF.
Here is a link to the EF team's blog, where they talk about adding Model First support in v2:
One of the most painful omissions from the Entity Framework V1 was Model First, which basically means creating a conceptual 'model first' and then deriving a storage model, database and mappings from that.
[...]
The next release of the Entity Framework will include the ability to generate database schemas from your model. The main entry point into this feature is via the Designer context menu, to which we will add a new option called “Create Database from Model”.