I am adding Code First migrations to an existing Entity Framework 6 domain with existing databases. I need the following behaviour:
If the database exists, insert the InitialCreate migration but do not perform the contents of the migration Up().
If the database does not exist, create it and run the contents of Up() and Down() to create an empty but correct-schema database.
I need (1) for when I release through the Continuous Delivery deployment. I need (2) for when a developer is cleaning down their machine and starting fresh. I do not want to use automatic migrations.
I appreciate that a Migration has no concept of the Database Context, it's only responsible for generating a series of SQL instructions.
Are these my only options?
1. Move contents of Up and Down out of InitialCreate and into Configuration.Seed
The InitialCreate migration runs Up() but no changes are made. In Seed() we have access to DbContext, so we can work out if the tables exist and create them if needed.
I think this might break when there are lots of migrations to run as Seed() is called after the migrations. On an empty database, the creation of the tables would be happening after updates to those schemas.
2. Perform the Up() method as a SQL Script
Migrations allows the developer to put inline SQL into Up() and Down(). Move the creation of the database into inline SQL and add a IF NOT EXISTS at the top.
I don't like this because you lose the use of the model that is supplied with the InitialCreate. If the model is updated, the fixed SQL string won't.
3. Empty out the Up() and Down() methods, do a release, put the creation code back in, do another release
When the InitialCreate migration is run first time, it won't have anything in it. The entry will go into the migrations database without running anything.
Once that first release has been performed, I can then put the creation code back in so that when future developers run it without a database, it will create properly.
Note: This one is my current favourite as it uses Entity Framework as designed and I can personally control adding the code back in after a release.
Is there a better way?
Edit
I am unable to build the database from empty, this might be something to do with the Context model creation. It uses a bespoke pluggable method:
public MyObjectContext()
{
((IObjectContextAdapter) this).ObjectContext.ContextOptions.LazyLoadingEnabled = true;
((IObjectContextAdapter)this).ObjectContext.CommandTimeout = 180;
}
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
System.Type configType = typeof(AnswerMap); //any of your configuration classes here
var typesToRegister = Assembly.GetAssembly(configType).GetTypes()
.Where(type => !String.IsNullOrEmpty(type.Namespace))
.Where(type => type.BaseType != null && type.BaseType.IsGenericType && type.BaseType.GetGenericTypeDefinition() == typeof(EntityTypeConfiguration<>));
foreach (var type in typesToRegister)
{
dynamic configurationInstance = Activator.CreateInstance(type);
modelBuilder.Configurations.Add(configurationInstance);
}
base.OnModelCreating(modelBuilder);
}
All the map objects are in the same DLL, the domain entities used for the database tables are in a separate DLL.
This is what we do:
1) Create an initial migration that is a snapshot of the current database. Use -IgnoreChanges to keep any code out of the Up(). You don't need the Up() code because EF will compare the prior model (blank) to the one stored in the migration and realize you need to add all the existing objects at the time of the snapshot.
add-migration Initial -IgnoreChanges
2) Add new migrations as you develop. In a team environment you could run into the issues outlined here: https://msdn.microsoft.com/en-US/data/dn481501
3) You can generate an idempotent script that will rebuild an entire system from scratch and apply any (or all) migrations.
Update-Database -Script -SourceMigration $InitialDatabase
https://msdn.microsoft.com/en-us/data/jj591621.aspx?f=255&MSPPError=-2147217396#idempotent
Related
I have an app and it has a database behind it. This app is deployed in multiple instances, where each instance has different version of code and database. By different version, I mean it might be slightly older version of code and database.
What I would like to do is:
Start using EF6 database migrations on the development version.
In correct order (dev->stage->prod), deploy to other instances the development version and update the database using EF6 database migrations.
Create new instance of app, using EF6 database migrations.
The question I am running into is this:
I understand that I can enable migrations on my development instance, then do Add-Migration Initial –IgnoreChanges and create incremental migrations for new database changes. As other environments will be updated, these changes will be applied (running Update-Database during deployment).
However, my question is, with this kind of setup, how to handle when I have to spin up a new instance of the app? I need a migration which would create all the tables. I know how to create this migration also: by pointing the connecting string to empty database and running Add-Migration. However, when I will deploy my code to existing instances and run Update-Database, EF will try to run this baseline migration and crash.
How to handle these two scenarios in a simple and automated way?
I guess I am imagining two types of migrations:
Update-Database -Baseline-And-Incremental
and
Update-Database -Incremental
Also, this will all be automated, so I dont want to run Update-Database and pass in the non-baseline migration names to run on existing database during deployment.
1st
In your DbContext constructor add
Database.SetInitializer(new CreateDatabaseIfNotExists<MPContext>()); //Create database if not existed
Database.SetInitializer(new MigrateDatabaseToLatestVersion<yourContext, Configuration>()); // uses the configuration for migrations for this DbContext
and your configuration class should look like this:
internal sealed class Configuration : DbMigrationsConfiguration<DBO.MPContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
}
}
AutomaticMigrationsEnabled = true; // enables automatic migrations
AutomaticMigrationDataLossAllowed = true;
//this kinda gives permision to delete a table, what I mean is say you have a one to
//many relation in a table and you decide to remove it for any reason by adding this
//code you allow the migration to delete the reference (Sorry for the bad english)
public class TEST{
public List<TEST2> test2 {get;set;}
}
if you decide to remove test from test it deletes the reference from TEST class (thereore you lose that data)
P.S if you are using an online DB you might need to add Persist Security Info=True to your connection string
Hope this helps
I Use code-first migration but I has error when run application.
error:Cannot find the object "dbo.Products" because it does not exist or you do not have permissions.
I have already got deleted Products table manually on sql server.I expect when Re-Run Project All table recreate if not exist in sql server.
In addition,I write 2 line for configure migration.
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = true;
any help ?
If you are using migrations you shouldn't "manually" change the database. So now EF is generating code to remove the table for you, but it doesn't exist. Solution is to comment out the code in the Up() method that removes the table and update-database. See https://msdn.microsoft.com/en-US/data/dn481501
If you want your database recreated, you will need to switch to an initializer such as DropCreateDatabaseIfModelChanges. See http://www.entityframeworktutorial.net/code-first/database-initialization-strategy-in-code-first.aspx.
I want Update database by code first migration .for example I have 3 entity in contex and 1 table in database and there is a problem when I run program and get this error:There is already table.
Migration Configuration
internal sealed class Configuration : DbMigrationsConfiguration<ApplicationDbContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
// AutomaticMigrationDataLossAllowed = false;
}
protected override void Seed(ApplicationDbContext context)
{
// This method will be called after migrating to the latest version.
}
}
IdentityModel
public ApplicationDbContext() : base("DefaultConnection" )
{
Database.SetInitializer<ApplicationDbContext>(new MigrateDatabaseToLatestVersion<ApplicationDbContext, Migrations.Configuration>());
}
any help ?
Have you tried to use the Add-Migration "migration_name" before calling update database? Or maybe try to use Update-Database -Force.
Otherwise, I have found some steps that maybe could be useful:
Remove the existing Migrations folder in your project, and DROP the table __MigrationHistory from the existing database.
Run the enable-migrations command from the Package Manager Console.
Run the add-migration command to create an initial migration.
Remove all of the code in Up() method for the initial migration.
Run the update-database command to apply the initial migration to your database. This doesn't make any changes to existing objects (because the Up() method contains no code), but it marks the existing database as having been migrated to the initial state.
Make changes to your code-first model.
Run the add-migration command to create a new migration. The code in the Up() method of the new migration will contain only the changes to your object model.
Run the update-database command to apply the changes to your database.
That's a common problem with migrations. When you add a new migration it compares the current code model to the prior code model stored in the prior migration. If this is the first migration it will thus generate code for everything, so sometimes the code will try to add objects that already exist.
To get past this, you can comment out the code in the Up() method of the migration for the items that already exist and then apply the migration (update-database). Now it will correctly generate just the changes moving forward.
To prevent this, you should always generate an initial snapshot of your database without generating any changes:
add-migration MyStartingPoint -IgnoreChanges // ignorechanges flag tells EF to just take snapshot with no code in Up()
Here is a document on how migrations operate "under the hood".
Code-First-Migrations is a excellent technology but for some reasons I can't use
static MyDbContext()
{
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyDbContext, Configuration>());
}
So I have to turn off migrations and delete all relevant records from __MigrationHistory
Database.SetInitializer<MyDbContext>(null);
When I change model I write a sql-script to make relevant changes in database.
My program has special module to execute these scripts. Such way customers can actualize their DBs when I change model. It's just part of update for them.
Does this approach have any pitfalls?
I have an MVC web application with code-first Entity Framework. We install this application in various computers as a local application. I made a migration to upgrade the database (in this case I added a new table), and after running the migration on upgrade, I want to insert initial data to the database so the users will be able to add/edit/delete them but I don't want the table to be empty at the first time.
Is there a way to do it automatically on upgrade without running a SQL script manually?
Migration class has up method,you can override it and insert/update records using SQL :
public override void Up() {
AddColumn("dbo.Posts", "Abstract", c => c.String());
Sql("UPDATE dbo.Posts SET Abstract = LEFT(Content, 100) WHERE Abstract IS NULL");
}
(Source)
Yes there is. You essentially write a class to conditionally check and insert values, and then you link this class to your entity framework database initialiser. It runs each time there is a migration to be performed, but I think you can change exactly when it runs (e.g. Application startup).
This link will give you the rough idea:
Entity Framework Inserting Initial Data On Rebuild
I have an exact code sample on my PC but I won't be on it until tomorrow. If this link doesn't quite do what you want, I can send you some code tomorrow which definitely will.