Update database schema in Entity Framework

Question

I installed VS SP1 and played around with Entity Framework.

I created a schema from an existing database and tried some basic operations.

Most of it went well, except the database schema update.

I changed the database in every basic way:

• added a new table
• deleted a table
• added a new column to an existing table
• deleted a column from an existing table
• changed the type of an existing column

The first three went well, but the type change and the column deletion did not followed the database changes.

Is there any way to make is work from the designer? Or is it not supported at the moment? I didn't find any related material yet, but still searching.

Answer 1

I would guess that possibly those don't happen because they would break the build for existing code, but that's just a guess on my part.

Here's my logic:

First, EF is supposed to be more than 1:1 table mapping, so it's quite possible that just because you are deleting a column from table A doesn't mean that for that entity, there shouldn't be a property Description. You might just map that property to another table.

Second, changing a type could just break builds. that's the only rationale there.

Answer 2

I've found that, in general, there are still quite a few bugs with the 'Update Model from Database' functionality.

Keys are the killer for me - I've yet to have any modification I make to a foreign-key relationship or to add a Primary Key to a table and have the updater work correctly (in that it will give a compile error on the generated code) - but to solve the problem it's a simple matter of deleting the model and re-importing (only takes a minute) - this is less than ideal obviously, but I've never had a failure from a 'fresh' import.

Answer 3

From the demos of the designer I've seen, it's not a flawless tool. It is a version 1.0 product, so it's bound to have some pain points. The change type is one of them it seems. From watching the designer and the code generation, I figured that one would break either at compile time (not likely) or at run-time (when the model is actually executed).

Answer 4

You need to delete the column by yourself from the designer or the XML file.

Answer 5

As mentioned before, you can just delete the column from the designer. As far as changing the data type of the column: just refresh the model from the database then go to the table mappings and select the column that you changed in the DB. the values on the right represent your model, oddly enough this does not get updated automatically, but just select the column to the right and go to properties and change the data type there. It should become a drop down menu.

Cheers.

Ruddy

Answer 6

I builded similar application like your requested. But my solution was to hard. I will try to tell;

1. You have to create your own database management clases and these objects will be responsible for create, update database schema (I created manually that).

2. I saw good article and source code on ADO.NET Team blog then you can also download EDMTools from this blog, it open source. And you can also implement model generation and update routines from that into your project.

3. Finally when the your schema changed you should recreate and bind your model and rebuild your data assembly during runtime. But you have to know most important think, you should tie your data model assembly to your project with loosely coupled (check out this post)

   Other way, you should wait for EF 4.0 release (it CTP 1 now), they announced that they will provide create,delete,update DatabaseScript functions.

Good lock

Answer 7

The way I'm doing this (and I'm doing all of the things you mention, plus renaming columns) is by making changes to the database and regenerating the EF code using EF Code First.

I'm not tampering with the EF Code First classes for the good or the bad (including nonsensically named columns for relations) to ease the process.

No designer or ORM schema generator will be able to make changes to your production database if it has constrained data in it. This is why you should always start with checking if your changes to the DB are feasible, try them on a development database and then adapt your code to reflect the changes.