Menu
Traditionally I have always written my sql scripts by hand so they are nice and clean (I'm not a fan of the generated ones) and release to release, I provide a fresh install script and a migration script from the previous version that creates new tables, alters existing tables etc. This is all pretty standard.
I haven't really had much time to play around with EF 4 code first but am quite interested to use it if it is actually viable in a production environment.
Say you have a code first approach where a database will automatically be created if one does not exist. What happens if you release a new version of the software which has schema/model changes. Is EF smart enough to update the database schema to match the updated EF model?
Scenario
Is code first only useful for initial deployment, or is it smart enough to update an existing database release to release like this?
252
Run the Add-Migration InitialCreate command in Package Manager Console. This creates a migration to create the existing schema. Comment out all code in the Up method of the newly created migration. This will allow us to 'apply' the migration to the local database without trying to recreate all the tables etc.
With EF Core, you deal with database schema changes by using migrations. When you first create the database, you create a migration that contains the initial definition of the database. As you make schema changes, you add new migrations and apply them on top of the existing migrations.
But a command that will “tweak” the generated code is on the EF Core roadmap and should be out sometime in 2018. 1. EF Migrations can be difficult EF migrations work well for a simple system, but they start to get complex when used on a live site.
With fluent mappings in Entity Framework code-first you can indicate the default schema at runtime. This is one statement in OnModelCreating in your DbContext subclass, for instance:
Anytime you change the definition of the database – from renaming a column to creating a table – it’s referred to as a database schema change. With EF Core, you deal with database schema changes by using migrations. When you first create the database, you create a migration that contains the initial definition of the database.
As of EF CTP4, your database will be dropped and recreated every time you change your object model (this is not the default convention and you have to explicitly tell EF Code-First to do so by setting a Database Initializer Strategy).
That being said, EF team are actively working on a Database Evolution (aka Migrations) Solution that exactly addresses your scenario: A solution that will evolve the database schema as your object model changes over time which essentially tries to alter the database to be back in sync with your model instead of recreating it.
As per EF team, this feature will be available as part of EF next version that is on track to be released on the 1st quarter of 2011.
53
The ability to create a database is just one feature of Code First - and it's an optional feature. You don't have to use this feature at all. In fact, Scott Gu has an entire blog post dedicated to using Code First with an existing database.
Until the Database Migrations are released, you have to come up with another strategy and that strategy will simply be managing your ALTER TABLE scripts as you traditionally would have. So when you deploy a new version, you run your ALTER script and deploy the code that contains the changes to the model.
Having said all that, you get more options in Code First than simply dropping and recreating your database every time (that is just one option). You can also set the initializer to only recreated the database if the model changes. You can also set the initializer to never run at all (in the case where you're manually managing changes to the database). This post will give you more information on EF database initializers.
39
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
