Where I work we haven't used EF data migrations. Others prefer to generate the SQL code to create tables, views, etc. with other tools, like TOAD. Then run the generated SQL. That's a function they're not willing to give up. I have thought that it wasn't possible to use EF's data migration.
Or at least that's what I thought, until I came across this link over the weekend. Code First Migrations with an Existing Database. I'd really like to know how we can do this at work. We have two teams working on the same problem. One is developing a web site app. The other is working on a WPF app. Both are using the same database, but different tables in different schemas. If we use the code first migrations with an existing database, then how to we coordinate migrations between two separate Visual Studio projects? There's only going to be one __MigrationHistory table in the database. The migrations must be maintained separately. How do we go about doing that?
We're working on a new WPF app. Because of this I do modify some of the model classes by adding the INotifyPropertyChanged (INPC) interface along with the code to implement it. In looking at the code that Code First with Existing Database generates, I can see how EF handles a 1-to-1 relationship. But I'm less certain about how EF handles a 1-to-many relationship. Therefore, I have a separate console app project I keep, where I can wipe out all the model classes, then reproduce them by going through Visual Studio's Add Item and add once again the model classes using Code First with Existing Database method. Then I'll have one instance of VS open to the console app, with another instance of VS open to the WPF app, where I copy code from those classes that have changed out of the console project into the WPF project. I do that because I don't want to wipe out the additional code I've added for INPC. If I go to using EF data migrations with the model classes code that has INPC logic in it, will that cause problems with the EF migrations?
We're working with EF 6.4.