Keep "Store Generated Pattern" saved when updating model.
When "Create from database" option is used - the Store Generated Pattern values i.e. "Identity" are lost. Those values should be remembered for tables that didn't change. Now user has to set each value manually after update.
-
AdminDevart (_, Devart) commented
See the details of the feature implementation in our blog article "New Features of Entity Framework Support in dotConnect Providers" at
http://www.devart.com/blogs/dotconnect/index.php/new-features-of-entity-framework-support-in-dotconnect-providers.html#StoreGeneratedPattern -
Roman commented
This preserves are only needed, if you have database first....
1 The data type changes should preserved in any situations where NUMBER(1) was not mapped to bool and vice versa
(for both ssdl and csdl)
2. The double -> decimal changing should be preserved as long as database precision/scale has not changed
(for both ssdl and csdl)
3. If you have more than one Association from one entity to the other, you will see a number at the end of the generated name, this we changed to a correct name for the association/navigation.
(only in csdl)
4. Couse of limited length for oracle identifiers,some unreadable shortcuts renamed in the conceptual mode to the expanded readable names, this must be preserved
(only csdl)
5. Self defined entities that are only queries over existing entities/tables mut be preserved.
6. Some times it occures, that if you generate the key columns in EF4, the name collides with an existing association and than you have to rename the association and this should also preserved.
7. We decided, to change the pluralisation for sets from "s" to "Entities" and the navigations from "s" to the correct german pluralisation
8. Splitted entities over one table must be preserved and all other entity mapping stuff with inheritance etc.9. You should preserve unchecked tables/views/materialized views and functions( all triggers!!!) from schema to avoid merge them, only new object should appear checked.
10. The specified key columns for views should be preserved.
some examples...
this.associationRenames["Arztgruppe_Arzt1Set"] = "Arztgruppe_ArztHwSet";
this.propertyRenames["Labeltyp"] = "Labeltypid";
this.propertyRenames["HatAssistent"] = "HatAssistentid";
this.navigationRenames["ArztAbstaffelungs"] = "ArztAbstaffelungen";
this.entityRenames["ArztV01"] = "ArztMitBescheid";
this.entityRenames["KvnoAlleAdressenMv"] = "KvnoAlleAdressen";
this.entityRenames["AbrExports"] = "AbrExportEntities"; -
AdminDevart (_, Devart) commented
1. Roman, can you explain the situation with changing names and types in more details. Should they be preserved always?
2. We will consider the functionality with German naming.
3. We will try to add the Number Mapping functionality in the near version. -
Roman commented
Do not only keep this one,
Keep also all renamed names for entity, entitySet, and Associations and data types on user selectable merge option
(pluralization works only with english language names, not readable and helpful e.g. with german naming),
also the impossibility of forcing the usage of decimal(n,m) instead of double does keep me away from using the your model update
(double does not support this precision/scale facets)You should keep all this changes in the edml.view and use this during updating of the model.
At the moment I have written my own xml model update tool, that merges a new created edml with my old one supporting all this things...
But it supports not all cases...)Roman
-
AdminDevart (_, Devart) commented
Do you mean Update from Database Wizard in Microsoft Entity Data Model Designer? Unfortunately, we don’t see any technical possibility to affect its storage model overwriting (re-generating) behaviour.
Yes, it is very inconvenient, especially for Oracle users. This is one of the reasons why we have developed Entity Developer - an ORM model designer which offers much easier and more flexible Entity Framework model development process. It is supplied with our providers.
Entity Developer allows editing storage model visually without changing XML code manually. Also in Entity Developer you can choose which changes to apply to the model objects when updating the model from database, i.e. you may apply only part of the changes without modifying manually edited objects.