How to deploy with automatic migration enabled? - entity-framework

I don't understand the concept of automatic migration.
Having set AutomaticMigrationsEnabled = true; in the Migrations.Configuration class I can't find the place where migration steps are stored.
How will Entity Framework recognize the current state of a production database and update it accordingly when, e.g., my console application is run at the customers' office?
Any information on this is very appreciated.

To answer your first question: They aren't stored anywhere. Automatic migrations only means that the migration will take place without you having to do anything about it. Generating a migration file only occurs when you are doing a manual migration. The only trace that automatic migration leaves is a new record in the _MigrationHistory table of your database--which will only be a serialized version of the new model, and not what your changes were.
To answer your second question: You shouldn't have to. Once you're in production, your client shouldn't be able to adjust the database themselves. That's just a terrible idea.

Related

Entity Framework Explicit Migrations

we have a project running Entity Framework 6.1 and we started using explicit migrations a while ago (in the past we would use automatic migrations) and we have run into the following situation.
I create an explicit migration to create some indexes on fields. I do this in a seperate branch.
A colleague of mine also starts an explicit migration to do some other work in his own branch.
Each branch is code reviewed and merged into the master branch when approved.
But now we noticed that my explicit migration to create the indexes, was created on a different version of the model. Since it's a project with multiple developers, the model is always changing. So if we check what SQL code would be generated to update the database, we see that new columns/tables/... that have been added in the meantime while I was working on my branch are being dropped, that my indexes are then created and afterwards those columns would be added again.
How can we avoid this? What are we doing wrong in our workflow?
With EF 6 each migration has metadata about last state of DB.
In EFCore this is much better done with separate file that has snapshot of DB.
Here are some good practices for Migrations in Team Environments:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
How to manage Migrations in a project with multiple branches?
Now your situation is pretty specific and I am not sure that any of these procedures has automatic solution for it.
One way I can think of is to have DB model not locally but on a server and that each developer targets that when creating migration.
However in the previous blogs shared DB was not considered best practice.
You would need to figure out some hybrid procedure to comply with every advice.
Good luck...

Manual synchronization between Context and Database using EF Codefirst

I'm using EF 5.0 (CodeFirst) with VS 2012. I changed my model (entity) and manually changed my database. I try to run the application and the following error appears:
The model backing the 'XXXContext' context has changed since the
database was created. Consider using Code First Migrations to update
the database (http://go.microsoft.com/fwlink/?LinkId=238269).
My only change was the name of the entity property (column in the database).
Its automate or ignore the synchronization? For the same has been done manually, only the application that does not recognize it. Or run something that validates manual synchronization.
Where is the recorded synchronization information for the application to know that there was a change?
Thanks
You have the option of using Database Initializers or Migrations. In your application startup you can enable initializers with the following:
System.Data.Entity.Database.SetInitializer<YourDbContextType>(new DropCreateDatabaseIfModelChanges());
You can also subclass and create your own logic if needed. See http://www.codeguru.com/csharp/article.php/c19999/Understanding-Database-Initializers-in-Entity-Framework-Code-First.htm for more info.
You can also enable migrations and let them automatically update your database. Running Enable-Migrations in the Package Manager Console does this. Look here for more information http://msdn.microsoft.com/en-us/data/jj591621.aspx

Incremental Database development in Entity framework code first

How can I do incremental developments with entity framework code first database. Because if I change something i model classes it will regenerate the database which cased to loss my data already in the database. I'm using DropCreateDatabaseIfModelChanges . Is there any thing other than that to execute alter quires rather than recreating.
EF Code First Migrations would help you here, it's in alpha/CTP currently: Entity Framework Code First Migrations: Alpha, also check out the ADO.NET team blog:
The most consistent request we have heard from you since releasing EF
4.1 has been for a migrations solution for Code First that will
incrementally evolve the database schema as you model changes over
time. Today we are announcing the release of our first Community
Technical Preview (CTP) of our Code First Migrations work.
As I recall, the Microsoft docs tell you to be sure not to use DropCreateDatabaseIfModelChanges in production environments. The point of that option is to help you come up with code-based data population for your test runs. I haven't seen any tools to help with incremental changes when using code-first. Where I work, we use a database-first setup, and we create a change script for each new release that includes alter and insert statements.
incremental database development is not currently available in the current version of the codefirst framework however it is included in the roadmap for the next release which will ship with MVC 4
as of right now you would need to remove metadata tracking from the database conventions and update the database manually via scripting or using the sql tooling until this new convention is added to the framework

Entity Framework 4.0 'Code First' approach

I've been working Entity Framework trying to get better with it. I'm liking what I'm seeing thus far but now have a question. With this new 'Code First' approach (from the CTP 4 download) we can now use EF from a code first approach, but I'm trying to find out if one can use an existing EDMX file with this approach.
I have a project I'm working on which has an EDMX file and I notice the ModelBuilder has a RegisterEdmx method but am not finding a lot out there on whether this will allow to use an existing EDMX file with my code first approach.
Also, I know with this new CTP things like RecreateDatabaseIfModelChanges are avilable but these options drop the database and recreate it, wont this cause all your data to be lost if you ever change your models? Is there something I'm missing here?
I can't speak to using previously generated EDMX files but there is support to use Code First with existing databases. As for the automatic Recreate, yes, this will kill all your data. This is meant only in rapid development where the persistence of data doesn't matter (and, in fact, is likely unwanted as you discover issues with business logic and want a clean start with your updates.)
This is meant only as a quick way to develop. As of (when Scott Guthrie blogged about the CTP - jump to section 5) there are no data migration features available. Your options are to manually update the database to match your model, delete the database and let it be recreated or set the automatic recreate option. Only the first option is non-destructive to your data.

How to hook an action after SaveChanges is successful

Our product has to be interfaced with multiple client/partner systems. For example, when a person is added/updated we have to notify changes to a 3rd-party system, for example by calling a web service or creating a xml file in a folder, etc.
We need a "hook" after SaveChanges has successfully persisted changes in the database.
Lots of information can be found about how to execute business logic when saving changes (before changes are persisted in the database), but less about executing logic after changes are persisted.
After investigating, I think to use the following:
// Persist data
cxt.SaveChanges(false);
// TODO: execute business logic that can get data changes
// Discard changes and set entities as unmodified
ctx.AcceptAllChanges();
Does anyone have a better solution for this scenario?
I know this question is a bit old, but figure that I would add this for anyone else searching on this topic.
I would recommend checking out EFHooks. The official version is a bit stale (e.g. .NET 4 only), but I have forked the project and published a new NuGet package, VisoftInc.EFHooks.
You can read more about both packages in this post: http://blogs.visoftinc.com/2013/05/27/hooking-into-ef-with-efhooks/
Basically, EFHooks will let you hook into EF (e.g. PostInsert or PostUpdate) and run some code. The hooks are Pre/Post for Insert/Update/Delete.
One thing to note is that this is based on the DbContext, so if you are still using the ObjectContext for EF, this solution won't work for you.
You can override savechanges, then do the updating of the 3rd party systems at the same time as you save the data to the database.
see: http://thedatafarm.com/blog/data-access/objectcontext-savechanges-is-now-virtual-overridable-in-ef4/