dotnet ef dbcontext scaffold: Bug in oracle to C# datatype mapping?

3818723

Hello,

i'm having a hard time to understand the mapping of Oracle datatypes to C# datatypes:

"Actual" is the result in my generated C# Class while "Expected" would be the more comprehensible result from my perspective.

create table Demo(  level                   NUMBER(1) not null,      -- Actual: bool     Expected: int  algorithm               NUMBER(1) default 1,     -- Actual: bool?    Expected: int?  manipulate_events       NUMBER(1) default 0,     -- Actual: bool?    Expected: int?  disabled                NUMBER(10) default 0,    -- Actual: int?     Expected: int?  tp                      NUMBER(10),              -- Actual: int?     Expected: int?  divisor                 NUMBER,                  -- Actual: decimal? Expected: decimal?  matrix_x                NUMBER(3),               -- Actual: byte?    Expected: int?)

Could you eleborate a bit why you choose such a mapping or kindly consider changing it within the next service release?

Tooling:

Oracle.EntityFrameworkCore Version 2.19.60

Microsoft.EntityFrameworkCore Version 2.2.6

Microsoft.EntityFrameworkCore.Relational Version 2.2.6

Microsoft.EntityFrameworkCore.Design Version 2.2.6

Microsoft.EntityFrameworkCore.Tools Version 2.2.6

Kind Regards

a frustrated user of your products

Alex Keh-Oracle

The "Actual" is consistent with what ODP.NET EF Core documents: https://docs.oracle.com/en/database/oracle/oracle-data-access-components/19.3/odpnt/EFCoreREDataTypeMapping.html#GUID-4F…

The reason for the mapping choices is that the EF Core provider model only allows provider writers, such as Oracle and MySQL, to have one set of default data type mapping. That one mapping has to work with both scaffolding and migrations. When .NET data type sizes do not map one to one with the DB data types, the provider writer has to decide whether to map so that inserts work without error or retrievals. Microsoft has advised Oracle to favor DB inserts in its EF provider, which makes sense. It's generally easier to modify the app than the DB schema.

If EF Core allows provider writers to define different mappings for scaffolding and for migrations, Oracle could then provide a more natural default data type mapping for scaffolding.

Until then, these mappings are only a default setting. Developers can change the mapping manually to whatever data type they prefer to use.

Alex Keh-Oracle

The "Actual" is consistent with what ODP.NET EF Core documents: https://docs.oracle.com/en/database/oracle/oracle-data-access-components/19.3/odpnt/EFCoreREDataTypeMapping.html#GUID-4F…

The reason for the mapping choices is that the EF Core provider model only allows provider writers, such as Oracle and MySQL, to have one set of default data type mapping. That one mapping has to work with both scaffolding and migrations. When .NET data type sizes do not map one to one with the DB data types, the provider writer has to decide whether to map so that inserts work without error or retrievals. Microsoft has advised Oracle to favor DB inserts in its EF provider, which makes sense. It's generally easier to modify the app than the DB schema.

If EF Core allows provider writers to define different mappings for scaffolding and for migrations, Oracle could then provide a more natural default data type mapping for scaffolding.

Until then, these mappings are only a default setting. Developers can change the mapping manually to whatever data type they prefer to use.