I am using entity framework code first migrations. Very first time I do not have migrations enabled. When I run the project it creates _migrationhistory table with one row in it.
Then I delete this table and ran application, it ran successfully. Now I add one more property to entity and try to run but it did not run complaining that model is not compatible with database.
My question is how EF and database knows model is changed or database is different than model without _migrationhistory table or migrations in code?
Entity framework first checks if the database has _migration history table. If it doesn't have one, it tries to create one and run all the migrations from the beginning and also inserts the migrations name as a record in the migration history table.
Because, you have deleted the migration history table, entity framework cannot compare its migration records with the migration files. Therefore, it tries to run all the migrations again. But, this database already has the table for the relevant entities. Therefore, an error message (model is not compatible with the database) is displayed to the user.
Related
I want to do code first development on an existing SQL Server Database. I have used the Scaffold-DbContext command to generate the entities that I want into the tables I want. That's great. But, there were previously code first migrations done to this database. So I deleted the __EFMigrationsHistory table in the SQL Database. Now I want to start doing migrations. Unfortunately, when I run Add-Migration, it generates migration code to generate all of the tables again. I don't understand how I am supposed to tell it that these tables already exist. When I am reverse engineering, how do I generate the migration of the stuff it's scaffolding for me in the existing database?
Code First Migrations uses a snapshot of the model stored in the most recent migration to detect changes to the model (you can find detailed information about this in Code First Migrations in Team Environments).
Source here.
Run Add-Migration InitialCreate –IgnoreChanges to create the initial migration from an existing database. Then update-database to simply add the migration to the _EFMigrationsHistory table.
After that, you are good to go brother.
I am in a situation where we have been using (code first) EF migrations against a database that is used as the backing store for two applications. Over the past year or so, we have successfully made DB changes via migrations.
However, at some point a few tables seem to have been manually added and we are now experiencing FK reference errors when we try to delete.
I have attempted the obvious, with the obvious result: Adding the models and generating a migration is going to attempt to recreate the tables in the database.
Is there a strategy to add these new tables to our data model and get our migrations up to date?
I have been updating my entities in development and that resulted in several migrations and update database commands, to a particular database.
What happens if I change the connection string (because the new database sits on a later version of SQL Server, for example) and then run the database update again? I have the impression that EF would detect the new database, run through all of my migrations, and produce one script and execute so that my new database has all the tables, columns, and relationships exactly as how the last migration left it. Can I just change the connection string and I'll get the new database as expected?
Many tell me that I have to create a separate deployment project for each database I want to manipulate with EF, but that seems rather tedious.
If there are different Tables and Columns it will bomb out right away with an Exception on the mismatched column/table name, if your databases are the exact same (and at the same Migration History), it should update it.
If you have two Databases that are not on the same migration history, you can run
Update-Database -TargetMigration migrationName
And this will effectively revert a Migration, just be sure to delete the migration that was added to the solution directory. (This sometimes happens when switching between branches / databases a lot, and may save you some time)
"Can I just change the connection string and I'll get the new database as expected?"
As long as the Migration History isn't mismatched and the Connection String is Pointing to the right place.
"Many tell me that I have to create a separate deployment project for each database I want to manipulate with EF"
If you are using Visual Studio, you can create different publishing profiles if needed
I am using EF 6 code first. As part of the code-based migration, I would like to rename the existing database after applying all the pending migrations. Can this be done?
I don't think this would be (easily?) possible (without causing errors)
If you rename the database during the migration it wont be able to write the migration out to the migrationhistory table as the connection string will still be pointing to the old database.
Perhaps a better option would be to build something into the system to rename the database and adjust the required configuration outside of EF entirely.
Code First Entity Framework, from versions 5 - 6.1.1+, with migrations enabled stores database updates as "migration" classes. Each class has an accompanying resource file containing a serialized version of the model, i.e. the entities, properties, relationships, etc.
This serialized version of the model is then stored in the database in the __MigrationHistory table with a single row per migration. The information in this table is used to check what model version a database is at and thus what migrations still need to be run. It is also used during some database initialization strategies to determine if the running code's model matches the last migration deployed to that database.
In neither of the use cases for the __MigrationHistory table is the fully serialized model needed. At best only a hash of the model would appear to be required.
As we've had our code first database running for a while, the __MigrationHistory table is storing 36K per row for a total of 4MB. This isn't huge but seems unnecessary.
So the question: Why doesn't Entity Framework store a hash of the model in the __MigrationHistory table?
When you changing your model and adding a new migration, EF migrations generates Up and Down methods for you. And these changes comes from comparing full model from previous migration to your actual model.