Partager via

Update Model – a Question of Identity – Part 1 of 3

  • Article

 I propose to explain the reason behind some of the oddities of the “Update Model from Database” functionality and hopefully answer some common questions that come up about it.

Before I get started let me note that this will be a fairly technical post split into three parts (I’ll post links to the other parts as responses to this one). There is also a good blog on this subject taking a look at the changes since our last release and showcasing some particular examples of the principles I will be explaining below. This blog is by Noam Ben-Ami at the following link: https://blogs.msdn.com/adonet/archive/2008/04/01/update-model-from-db.aspx.

An EDMX file represents the conceptual (C-) side of the model, the storage (S-) side of the model and a mapping between the two. The major job of “Update Model from Database” is to update the S-side of the model to be consistent with any changes that have been made to the database since it was created or last updated. (Note that in this sense “changes” can also include any database objects which you chose not to include in your S-side model the last time through). “Update Model” will also automatically remove any mappings which would target non-existent S-side objects after the update.

For RTM, the S-side of the model is completely replaced by a new S-side model generated from all the tables/views/stored procedures in the existing model plus any new ones selected via the “Update Model from Database” wizard. This has the advantage of ensuring that the new S-side model is self-consistent, but has the disadvantage that it removes any S-side elements which have been added by hand to the EDMX file. We are considering alternatives to this approach for V2.

Now before we go on note that the Entity Designer shows you only the C-side of your model, not the S-side. The S-side is only visible through the Browser and entries in the Mapping Details window. Hence most people’s view of “the model” is the C-side of the model.

Note also that for any given S-side model there are many possible C-side models which could be mapped to it: in particular in addition to the more simple 1:1 scenario, two or more C-side EntityTypes can be mapped to the same underlying table, or a single C-side EntityType can be mapped to more than one table.

Although the major job of “Update Model from Database” is to update the S-side, we decided that, in order to reduce work for the user, we would also update the C-side but only under the following rule:

· The C-side updates would be non-destructive.

This means that we feel free to e.g. add new C-side EntityTypes to represent new S-side EntityTypes or new C-side Properties to represent new S-side Properties, but we will not e.g. delete a C-side EntityType because we believe the S-side EntityType it was mapped to has been deleted. Nor will we “resurrect” a C-side EntityType which the user has chosen to delete. We leave such decisions up to the user.

As a consequence of this it is possible that an Entity Data Model which passed validation before “Update Model” was run will no longer be valid after “Update Model” is run. In this case the user should investigate each error message in the Error List Window and manually take some action to update the model before it can be used. The action that needs to be taken is probably destructive and so we leave it up to the user to decide.

In the next article I’ll explain how “Update Model” makes the decision to create new C-side EntitySets based on new S-side EntitySets and what “identity” has to do with all this.

Lawrence Jones
Software Design Engineer, Entity Framework Tools

Comments