Our product uses both EF "Model First" and "Code First" approaches simultaneously. In order "Code First" parts can work with dotConnect for Oracle, we have to explicitly remove ColumnTypeCasingConvention for every DbContexts in the application. Istead, we would like to just set the ColumnTypeCasingConventionCompatibility option to "true" for the entire application - but we can't, since it breaks the "Model First" parts (causing ObjectContext to fail with errors like "The type NVARCHAR2 is not qualified with a namespace or alias").
Even though this behavior is documented, the option is pretty useless in such "mixed" scenarios. Is there any chance to make the option affect only Code First logic (DbContexts) - as the name of its its section implies (CodeFirstOptions), leaving "Model First" bits (ObjectContext) intact?
P.S. This forum post http://forums.devart.com/viewtopic.php? ... patibility seems to describe the similar problem, that apparently have already been fixed, but in fact it is not.
CodeFirstOptions.ColumnTypeCasingConventionCompatibility
-
- Posts: 57
- Joined: Tue 11 Mar 2014 07:49
Re: CodeFirstOptions.ColumnTypeCasingConventionCompatibility
We have answered you by e-mail.
Re: CodeFirstOptions.ColumnTypeCasingConventionCompatibility
The functionality of setting the CodeFirstOptions.ColumnTypeCasingConventionCompatibility option via provider manifest token for a particular Entity Framework model is implemented for possibility of using both Database-First/Model-First model with XML mapping and Code-First model with fluent/attribute mapping in the same AppDomain.
With the new (8.3.161) build of dotConnect for Oracle, the feature should used in the following way:
1) for Code-First model with fluent/attribute mapping, set ColumnTypeCasingConventionCompatibility to True in the code
or in *.config file of the application
2) for Database-First/Model-First model with XML mapping, edit edmx/edml file with XML Editor and add information about ColumnTypeCasingConventionCompatibility in provider manifest token. For example:
a) before a change
b) after the change
For more information about the new build, please refer to http://forums.devart.com/viewtopic.php?f=1&t=29592.
With the new (8.3.161) build of dotConnect for Oracle, the feature should used in the following way:
1) for Code-First model with fluent/attribute mapping, set ColumnTypeCasingConventionCompatibility to True in the code
Code: Select all
var config = Devart.Data.Oracle.Entity.Configuration.OracleEntityProviderConfig.Instance;
config.CodeFirstOptions.ColumnTypeCasingConventionCompatibility = true;
2) for Database-First/Model-First model with XML mapping, edit edmx/edml file with XML Editor and add information about ColumnTypeCasingConventionCompatibility in provider manifest token. For example:
a) before a change
Code: Select all
ProviderManifestToken="Oracle, 11.2.0.1"
Code: Select all
ProviderManifestToken="Oracle, 11.2.0.1; CodeFirstOptions.ColumnTypeCasingConventionCompatibility=False;"
Re: CodeFirstOptions.ColumnTypeCasingConventionCompatibility
It is better to add ";CodeFirstOptions.ColumnTypeCasingConventionCompatibility=False" in ProviderManifestToken via interface of Entity Developer (the Provider Manifest Token property of EntityContextModel). This will allow not to overwrite the setting when modifying/saving model in future.Shalex wrote:for Database-First/Model-First model with XML mapping, edit edmx/edml file with XML Editor and add information about ColumnTypeCasingConventionCompatibility in provider manifest token