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.
Related
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.
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?
Following my question Entity Framework Migration: Why does it ignore snapshot and take __MigrationHistory into account?, I'm confused why EF migrations stores previous model both in DB inside __MigrationHistory table and in resource files? And more confused why does it completely ignore resources and consider the table data to calculate model changes?
I'm using VS2012 and creating a sample Entity Framework project that reads and writes to some tables that are used for import purposes. and do not have PK's or FK's in them - just null/notnull on the columns.
Can/should EF be made to insert records on these tables without that cryptic error:
Unable to update the EntitySet because it has a DefiningQuery
and no element exists in the
element to support the current
operation.
Or should I be looking elsewhere for database I/O?
Thanks!
Corey.
Is there a way to tell EF not to update SSDL for the single table when doing Update Model From Database?
A little more details:
We're using EF 4.3 with Db-first approach (so, edmx and Update Model From Database).
We have a table that for some reasons does not have a primary key set in SQL Server, but have an auto-incremented Identity column that we can tell EF to use as primary key.
Since EF isn't finding any primary key in a table itself, it generates a DefiningQuery in SSDL for that table (and prevent update/inserts).
I can easily delete that DefiningQuery (and modify other EntitySet attributes) and everything works fine.
Except when I do another Update Model From Database that DefiningQuery is back again.
Is there a way to tell EF not to update SSDL for that single table?
Is there a way to tell EF not to update SSDL for the single table when
doing Update Model From Database?
Not with default designer provided in Visual Studio. Once you modify SSDL part of your EDMX file you should maintain it manually or write a script which will fix it every time you run Update from database.
Alternatively you can buy more powerful designer or extension to Visual Studio which will offer you selective update.
Anyway what you are trying to do should be avoided. If the database is owned by ERP you should do the access only through ERP programming API (real ERP has some). Otherwise you can break functionality of your ERP, corrupt ERP data, cause performance issues or even cause deadlocks.