Following on from my post of Code First with entity framework. Each time I wanted to make changes to the database I went through the process of dropping the database and then regenerating it. This is fine during the development phase and especially if there’s no data to reimport to it. But let’s look at an alternative to this and something more likely to be of use when amending an existing database with a changed schema.<\/p>\n
Migration commands are used to generate change tracking files. The commands are run via Visual Studio using the Tools | Library Packager Manager | Package Manager Console.<\/p>\n
So load up the Package Manage Console (if it’s not already running) in Visual Studio. <\/p>\n
The first thing we need to do is enable migrations on the project. This basically sets up the migration configuration files etc. ready for you to start migrations. So run<\/p>\n
\r\nEnable-Migrations\r\n<\/pre>\nand you’ll see a Migrations folder added to your project as well as a Congiruations.cs file and an _InitialCreate.cs file (and associated designer.cs and .rex files).<\/p>\n
If you first take a look at the Configurations.cs file you’ll see a pretty empty file which can be used to seed data or handle other migration configuration code.<\/p>\n
The _InitialCreate.cs file is where the code exists for actually recreating the current database tables.<\/p>\n
Okay, so now we want to make some actual changes to our database. So continuing to use the sample code from the Code First I need to add dimensions to the Planogram, so my new code will look like this (new code highlighted)<\/p>\n
\r\npublic class Planogram\r\n{\r\n public int Id { get; set; }\r\n public string Name { get; set; }\r\n\r\n public double Width { get; set; }\r\n public double Height { get; set; }\r\n public double Depth { get; set; }\r\n\r\n public virtual ICollection<Product> Products { get; set; }\r\n public virtual Store Store { get; set; }\r\n}\r\n<\/pre>\nIf we now write some code to populate the new fields and run our application we’ll get an InvalidOperationException stating that the model backing the database context has changed. In other words we’ve changed the model but the DB is not in sync. The exception kindly notes that we should consider using Code First Migrations to update the database. So that’s what we’ll do next (for completeness the new coe to create the Planogram is listed below)<\/p>\n
\r\nusing (StorePlanDatabase storePlanDatabase = new StorePlanDatabase())\r\n{\r\n Planogram pegboard = new Planogram\r\n {\r\n Name = "Batteries Pegboard",\r\n Depth = 50,\r\n Height = 1000,\r\n Width = 800\r\n };\r\n storePlanDatabase.Planograms.Add(pegboard);\r\n}\r\n<\/pre>\nSo now back to our Package Manager Console and we need to create a migrations script for the changes to the model and thus the changes required to bring the database into sync with the model. At the Package Manager Console command line type<\/p>\n
\r\nAdd-Migration PlanogramDimensions\r\n<\/pre>\nPlanogramDimensions is the descriptive name we’re giving to these changes to the model. If you don’t enter a name you will be prompted for one. A new file _PlanogramDimensions.cs (and it’s associated Designer.cs and .resx) are created. If you take a look into this file you’ll see code specific to adding (and dropping) the new columns on the Planograms table.<\/p>\n
At this point the database has not been updated, this has just created the required “patch” if you like. So now from the Package Manager Console run<\/p>\n
\r\nUpdate-Database\r\n<\/pre>\nThis will run the migrations script and patch the db it will also run the seed data method from the configurations. If you now check the db you’ll find the Planograms table has the new Width, Height and Depth fields.<\/p>\n","protected":false},"excerpt":{"rendered":"
Following on from my post of Code First with entity framework. Each time I wanted to make changes to the database I went through the process of dropping the database and then regenerating it. This is fine during the development phase and especially if there’s no data to reimport to it. But let’s look at […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[3,21,2],"tags":[],"class_list":["post-149","post","type-post","status-publish","format-standard","hentry","category-c","category-entity-framework","category-programming"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/149","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/comments?post=149"}],"version-history":[{"count":14,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/149\/revisions"}],"predecessor-version":[{"id":172,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/posts\/149\/revisions\/172"}],"wp:attachment":[{"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/media?parent=149"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/categories?post=149"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/putridparrot.com\/blog\/wp-json\/wp\/v2\/tags?post=149"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}