MustFix: EF Designer may blindly overwrite facets of C-Space properties based on facets of S-Space properties


There is a new feature in EF Designer in VS2012 where we update facets of C-Space properties based on facets on S-Space properties. This is done to propagate changes the user made to the database to the C-Space (in VS 2010 only SSDL would be updated leading to discrepancies between C-Space model and S-Space model). However in some cases (e.g. Oracle) the discrepancy is intentional and brings additional information needed to map types correctly. Overriding facets blindly (i.e. without asking the provider first) in such cases is incorrect. Propagating facets can be disabled by setting Update Property Facets property to false. However this will work only when updating the model from the database and not when when generating the model from the database since there is no edmx file in such a case and, even if there was, EF Designer ignores it. Running facet synchronization when creating the model from the database is not needed since there is no custom code between generating the model from the database and propagating the facets nothing could change.
Conclusion: We should not run the facet propagation step at all when creating the model from the database. We should make sure that we ask provider for the types the provider knows in order to prevent overriding facets that are not supposed to be overriden.
Workaround: Instead of creating the model from the database create an empty model. Set the Update Property Facets setting to false. Update the model from the database.

Note: we will use this hug to track the porting of the minimal fix we did that special cases the SQL Server provider. We have a separate bug to consider the removal of facet propagation: http://entityframework.codeplex.com/workitem/642.
Closed Dec 10, 2012 at 6:26 PM by moozzyk
Shipped in VSUpdate1, ported to the OSS version.


moozzyk wrote Sep 27, 2012 at 4:30 PM

The fundamental issue with the EF Designer is that it does not use the object model that runtime uses. Rather than operations are performed on EFArtifact instances which are just abstractions of the Xml containing CSDL, SSDL etc. This is not only not correct but also makes the EF Designer duplicate code we have in the EF runtime assemblies (e.g. when talking about properties and types - in the EF Designer the whole object model is duplicated but different, for facets we calculate default values on our own etc.) which may result in discrepancies in behavior if there is a change in the EF runtime but not the designer.
Regarding types and properties - due to most of TypeUsage ctor overloads being not public - EF Designer cannot use actual property TypeUsages without having to load the whole artifact to an ItemCollection. Since we don't load the artifacts if the EF Designer needs a TypeUsage it creates one using TypeUsage.CreateDefaultTypeUsage(EdmType) factory method which results in having a generic TypeUsage that is basically useless for facet propagation because it does not have the facets that are defined on the property. With the TypeUsage created like this there is no point in asking the provider about a corresponding EDM/StoreType because the returned type wouldn't be usable either. The real solution here would be to make EF Designer work on MetadataWorkspace and generate artifacts based on MetadataWorkspace and not the other way around. The problem is that this would require a rewrite of the Designer and also making MetadataWorkspace mutable (which is not at the moment). For now we will turn off the feature for non-Sql providers.

moozzyk wrote Sep 27, 2012 at 4:33 PM

Looks like propagating all the facets blindly may be troublesome in some cases:

RoMiller wrote Nov 27, 2012 at 6:37 PM

This issue is fixed in Visual Studio 2012 Update 1 - http://www.microsoft.com/visualstudio/eng/downloads#d-visual-studio-2012-update

We are leaving this work item active to track porting the fix to our EF6 code base.