{"id":587,"date":"2016-02-07T13:10:54","date_gmt":"2016-02-07T13:10:54","guid":{"rendered":"http:\/\/tpodolak.com\/blog\/?p=587"},"modified":"2016-02-08T18:36:07","modified_gmt":"2016-02-08T18:36:07","slug":"entityframework-sqlexception-during-database-migration","status":"publish","type":"post","link":"https:\/\/tpodolak.com\/blog\/2016\/02\/07\/entityframework-sqlexception-during-database-migration\/","title":{"rendered":"EntityFramework – SQLException during database migration"},"content":{"rendered":"

Recently I’ve been doing some small refactoring of my pet project. Nothing too fancy – just namespace adjustment, variables and class renaming etc. However it turned out that even these minor changes can in fact be major ones. All of the sudden most of my integration tests started failing due to SQLException<\/i>.
\n\"Exception\"<\/a>
\nI am using Code First<\/i> approach so I didn’t take me too much time to realize that for some reasons EntityFramework<\/i> wanted to create already existing tables. I started looking into the way EF<\/i> keeps track of the changes in the model and it turned out that it creates special table called <\/p>\n

\r\n__MigratoinHistory\r\n<\/pre>\n
\"ContextKey\"<\/a>
\nOne of the most important columns in there is column called ContextKey<\/i>, which identifies the class which describes migration policy. In my case this class originally looked that way<\/p>\n
\r\nnamespace EFAutoupgradeException.Data\r\n{\r\n    public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration\r\n    {\r\n        public AutoupgradeExceptionMigrationConfiguration()\r\n        {\r\n            this.AutomaticMigrationsEnabled = true;\r\n            this.AutomaticMigrationDataLossAllowed = true;\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
In that case value of the ContextKey<\/i> column matches the full name of the class <\/p>\n
\r\nEFAutoupgradeException.Data.AutoupgradeExceptionMigrationConfiguration\r\n<\/pre>\n
The class after refactoring was slightly changed and now it looks that way<\/p>\n
\r\nnamespace EFAutoupgradeExceptions.Data\r\n{\r\n    public class AutoupgradeExceptionMigrationConfiguration : DbMigrationsConfiguration\r\n    {\r\n        public AutoupgradeExceptionMigrationConfiguration()\r\n        {\r\n            this.AutomaticMigrationsEnabled = true;\r\n            this.AutomaticMigrationDataLossAllowed = true;\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
It is easy to overlook the change but now, full name of the class is <\/p>\n
\r\nEFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration\r\n<\/pre>\n
so EF<\/i> loses the information about the migration and tries to migrate once again from the scratch. Fortunately there is an easy fix for that which doesn’t require dropping the database. All you have to do is to write simple update statement which set the proper ContextKey<\/i> value. <\/p>\n
\r\nUSE EFAutoupgradeException\r\nUPDATE [__MigrationHistory]\r\nSET\r\n[ContextKey] = 'EFAutoupgradeExceptions.Data.AutoupgradeExceptionMigrationConfiguration'\r\nWHERE [ContextKey] LIKE '%AutoupgradeExceptionMigrationConfiguration'\r\n<\/pre>\n
Source code for this post can be found here<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
Recently I’ve been doing some small refactoring of my pet project. Nothing too fancy – just namespace adjustment, variables and class renaming etc. However it turned out that even these minor changes can in fact be major ones. All of the sudden most of my integration tests started failing due to SQLException. I am using […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,39,285],"tags":[182,183,286],"class_list":["post-587","post","type-post","status-publish","format-standard","hentry","category-ef","category-entity-framework","category-migration","tag-ef","tag-entity-framework","tag-migration"],"_links":{"self":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts\/587","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/comments?post=587"}],"version-history":[{"count":8,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts\/587\/revisions"}],"predecessor-version":[{"id":599,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/posts\/587\/revisions\/599"}],"wp:attachment":[{"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/media?parent=587"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/categories?post=587"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tpodolak.com\/blog\/wp-json\/wp\/v2\/tags?post=587"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}