What is the best practice when the database schema changes in entity framework?

Question

I am using Entity Framework to do the ORM in .NET project. The problem I am facing is that when the database schema changes, there is no proper mechanism to update the edmx file.

For example, If there is a column called "Salary", and I change it to "EmpSalary", then when I update the edmx from visual studio and it shows me two columns in the class - Salary and EmpSalary.

One way I figured out is to delete the entire edmx file and regenerate it. But then what if I have manually renamed the navigation properties in the model? I will lose them and I have to recreate them which is a painful thing to do every time.

Any best practices in this area?

Thanks

Answer 1

The approach I used with Linq To SQL (which has the same issue) is to script my manual changes to the xml file so that I could reapply them after re-running generation process. You can generate a class library for editing the edmx file using Linq To Xsd. See http://www.adverseconditionals.com/2008/05/scripting-changes-to-linq-to-sql-dbml.html for a bit more detail

Answer 2

In the EF1 designer, the "Update Model From Database" function is broken for a lot of situations. I've been working with EF1 for about a year now. Problems using the EF1 designer have cost me days of time so as far as I'm concerned the best practice is to manually edit the EDMX XML yourself.

For tricky stuff, create a new model containing the new tables / columns / relationships / views you want and then copy-paste the XML from the new EDMX into your existing XML.

Some things it breaks when you use "Update Model From Database"

1. Overwrites any manual changes you make to the XML.
2. Can't cope with default values in the database - insists your entities provide values for fields that are populated by default-value.
3. Generates ludicrous compound keys for views and even if you've fixed the view to have sensible keys, it comments out the your correct version and creates a new version using its own weird keys!
4. Doesn't set all the attributes for columns added to tables that it sets when you create the table from scratch (eg Unicode, MaxLength, FixedLength)

I'm sure there are more, but this was enough for me to stop using it.

Answer 3

I have a few pretty large models that I assist in updating and the most important thing I have noticed about the "Update Model From Wizard" command in EF v1 is that it does not delete ANYTHING from the CSDL. The SSDL might be 100% correct (and is in most cases). So there are two ways to handle this.

1) Modify / script the XML changes. 2) Make the changes manually in the designer.

I have tried very hard to get method 1 to work. It's not easy, but basically the best hint I can give you is to compare the SSDL to the CSDL version and you get very close (if you are only talking about columns).

The worst part is when you rename a table. Then every FK relationship that was built on that table in the CSDL is essentially duplicated (because a rename is really a delete / create, but then remember the wizard doesn't delete anything in the CSDL :-))

So, the easiest tip I have. Make your changes from the update wizard. Then compile only the .edmx project (keeping the designer open). After that is done, just double click on each error message and 'resolve the error'.

Resolving the error depends on the scenario. If it's duplicated columns, right click on the bad column name and click delete. If it's a bad FK, right click on that and delete it.

I remember someone on codeplex attemtping to do the update wizard with T4 templates (what they use with .NET v4 now). I just think it is a LOT trickier than it first sounds. I had attempted to do it, and when I got to scenarios such as 1..* *..1 multiplicity the xml and code in the t4 generator got really scary. So instead we just resort to 'resolve the errors' method.