I am trying to decide code first migration strategies but not sure that which is better one.
I actualy liked automatic migrations but not sure that it can create more headache.
I have read this article and he is advocating code-based migrations. But i will not need to switch to different state in migrations so i will always use latest one and i am working in the project as single developer.
Suggestions ?
Automatic migrations were initially also referred as "with-magic migrations" whereas code-based migrations were referred as "no-magic migrations". These two names reflect exactly what is going on. Automatic migrations are implicit - you simply don't care and let them run as they need to. Code-based migrations are explicit - you define migrations in predefined steps and EF guides you in this (for example by not allowing more than one pending migration).
If you just want to have your database always up to date and you don't expect to support multiple versions or downgrades you should be OK with automatic migrations.
Related
I've seen this question, and I'm wondering how automatic migrations mixed with explicit migrations would be applied on the production environment.
Let us say I create migrations in the following order:
Explicit Migration A
Explicit Migration B
Automatic Migration C
Explicit Migration D
Since no file is created for the automatic migration, how can we be sure that the automatic migration SQL that will be created on the production environment will be the same as the one created on our development machine ?
I have a sense that as soon as we have a first release on production, we should purely stop using automatic migration...
I've experimented with such scenarios before and given your migrations order this is how EF is going to behave:
When you have all those applied to database and you execute Update-Database -TargetMigration:0, then all of them will be reverted in the same order as applied.
When after execute Update-Database, all explicit migrations will be applied to the database, and given you have set AutomaticMigrationsEnabled = true; the [Timestamp]_[YourLastMigrationName]_AutomaticMigration be applied.
Beware of the fact, that EF handles the order of execution of automatic migrations! I thought that issues would occur, when I created a new table XY in the automatic migration and the following Explicit Migration D could rely on that table to be in database (and many other scenarios). But since the migrations have the snapshots of database in them, EF will be able to recover from this situation and somehow rearrange the automatic migrations.
To conclude: Without digging into entity-framework's code, I don't recommend such approach - wouldn't try my luck. In my projects I only use explicit migrations, that are maintained in one specific - usually master or iteration branch only (because of the issues when one team member has created migration B on top of A and another has created C on top of A).
I'm using EF6 code-first migrations for existing database but initial DbContext does not fully cover existing schema (since it's massive). So from time to time I have to make updates to the model in database-first style. For example when I need an entity mapping for a table or a column that is already in the database but not reflected in the code I do the following:
Make all change (add new entity, rename the column mapping or add new property)
Scaffold migration representing the latest model snapshot stub_migration
Copy-paste latest serialized model from stub_migration to the last_migration resource file
Delete stub_migration
Revert last_migration in database
Update-Database so that model snapshot in [__MigrationHistory] table would be also updated
I understand that this aproach is a bit hackish and the proper way would be to leave empty stub_migration but this would force lots of empty migrations which I would rather avoid.
Looking at a similar scenario from MSDN article (Option 2: Update the model snapshot in the last migration) I wouldn't imagine that there is an easier way rather than writing power shell script, managed code or both to make it work. But I would rather ask community first before diving deep into it.
So I wonder: is there a simple way to automate generation of new model snapshot in latest migration and reaplying it?
I'm doing something similar. I have a large database and I am using the EF Tools for VS 2013 to reverse engineer it in small parts into my DEV environment. The tool creates my POCOs and Context changes in a separate folder. I move them to my data project, create a fluent configuration and then apply a migration (or turn automigration on).
After a while I want a single migration for TEST or PROD so I roll them up into a single migration using the technique explained here: http://cpratt.co/migrating-production-database-with-entity-framework-code-first/#at_pco=smlwn-1.0&at_si=54ad5c7b61c48943&at_ab=per-12&at_pos=0&at_tot=1
You can simplify the steps for updating DbContext snapshot of the last migration applied to database by re-scaffolding it with Entity Framework:
Revert the last migration if it is applied to the database:
Update-Database -Target:Previous_Migraton
Re-scaffold the last migration Add-Migration The_name_of_the_last_migration which will recreate the last migrations *.resx and *.Designer.cs (not the migration code), which is quite handy.
Those 2 steps are covering 4 steps (2-5) from original question.
You can also get different bahavior depending on what you want by specifying the flags -IgnoreChanges and (or) -Force
And by the way, the major problem with the updating the DbContext snapshot is not how to automate those steps, but how to conditionally apply them to TEST/PROD environments depending on whether you actually want to suppress the warning because you've mapped existing DB-first entities in you DbContext or you want it it to fail the build in case you've created new entities and forgot to create a code-first migration for them.
So, try to avoid those steps altogether and maybe create empty migrations when you just want to map existing tables to your code.
I'm using EF 5.0 and I would like to start using Code-based migrations
I've used fluent migrator and there is a concept of migration order. Migrations can be migrated/rollback no matter the database's migration version.
Does Entity Framework have similar functionality?
I was planning on keeping multiple migration implementations for each database version (likely tied to sprint number at first).
Why do i want this?
Our continuous integration will migrate the database for each environment. It's likely that our Dev build will only be one version "behind" but when we go to QA or PROD environment the database will be behind by multiple migrations.
Maybe i'm going about this the wrong way, in which case I would love to hear opinions on the best way to do migration with CI.
Yes EF has this functionality.
When you run Add-Migration you'll notice the migration file is prefixed with a timestamp. This is what determines the order, assuming automatic migrations are and always have been disabled.
If you are using a mixture of explicit migrations and automatic migrations then you may notice an additional Source property in the .resx file generated with your migration. This is how EF will determine if it needs to run an automatic migration before it runs your explicit migration.
My experience has taught me these guidelines:
1) Never use automatic migrations.
2) Every developer on your team should ensure they have the latest code before creating a new explicit migration. Sort of obvious, but creating migrations from stale code will result in problems.
3) Developers should make sure that if they write custom SQL in the Up() method of the migration then they write appropriate code (and test it!) to reverse those changes in the Down() method.
Background:
I'm developing an application with Entity Framework Code First and have been using my POCO Model to describe the database schema as much as I can. However there are a few cases where only the migrations API supports what you want (such as adding an index). I didn't want to start adding migrations until later, it's much faster just to recreate the database at this point, however it seemed like the only option.
So I thought I'd see if I could see if migrations would work. I planned on using them eventually and I was hoping I'd just be able to adjust the Initial migration or regenerate it as I went, until it was time to make real migrations. However I had no real luck with this approach either. It seems like code migrations for entity framework are fundamentally flawed in that they force the schema to be stored (serialized) as part of the migration.
For me it meant that there was no possible way to adjust the migration as I had no way to update the Target property (which is essentially a serialized version of my model). I also can't regenerate the migration because there is no way to express the indices separately. Part of the problem is that the way migrations work forces them to be made in a serial fashion, which is terrible when I want to update past migrations or there are multiple developers.
I've therefore chosen to just use context.Database.ExecuteSqlCommand to add the indices however I want to figure out if this limitation in migrations is going to change in the future or if I can work around it.
Question:
Is there any way to update the IMigrationMetadata for an existing migration and is there a way to have a migration that doesn't need the metadata found in the Target field?
I'm using Entity Framework and Entity Framework migrations to implement solution using code-first and automatic migrations.
It used to work great but suddenly it stopped detecting the updates I make to my POCO. Now when I add a new property (very simple properties like age or email) and execute the Update-Database, nothing happens, and it gives me this:
Specify the '-Verbose' flag to view SQL commands being executed during migration.
Found 0 pending explicit migrations: [].
Adding seed data (if Seed method overridden in Migrations Settings class).
and nothing gets updated!
Has anyone any idea why this is happening?
This may be in two reasons:
There is some other DbContext in code, that's why automatic migrations could not decide, which context to use.
There is some new change, which loops a comparison of schema and code model, so EF simply could not find the difference.
In general, automatic migrations are simple and fast to implement, but it is not secured to use them. On some stage, such migrations could make a fail.
Several years ago, I have developed tiny ORM based on Linq2SQL, AcroDB Library, and it was using automigrations of SubSonic. Almost same as EF migrations can do now. It was perfect on small projects and small amount of data to process or change, but when project has grow into 15+ tables, it became a nightmare. That's why MS has announced Code-driven migrations lately. They are more secured and better for the project. Also, you can take a look to Migrator.Net (it is a bit better than EF, by this time).