EF Core 3.1 Beta 2: Slower performance when using Date data type

I can’t find the link to Oracle forum anymore (and anyway, I find them pretty not user friendly), so I’ll post my issue here. As I said in my previous post, I’m experiencing major performance degradation (or simply an issue) when using dates.

I have the following query:

var doorCrossings = await _oracleContext
    .DoorCrossings
    .AsNoTracking()
    .Where(dc => dc.Matricule == user.Matricule && dc.CrossingAt.Date == date.Date)
    .OrderBy(dc => dc.CrossingAt)
    .ToListAsync();

Note that I’m using the “Date” property of the dates because I don’t want to take the time into account.

The “Matricule” field is “varchar2(16)” and “CrossingAt” is a “Date”. There is an index in the table based in these two fields. When running this query in the .NET 2.2 version, it is very fast (1-3s, there are millions of lines in this table).

However, when running the exact same query on the exact same database with the version 3.1 of the provider, the query execution never ends. I put a break point to the next line and it never gets hit and I don’t see any exception in the output.

To help investigating, I put the logging level to “Information”. When doing it with the 2.2 version, I see the query but I don’t see it with the 3.1 version. I tried removing the second part of the condition and then, I see the logs (I don’t get the results but there is no index on the “Matricule” field alone so it can be that it takes a long time to execute).

The part date of the generated query in 2.2 is

AND ("TRUNC"(FIELD) = :date_Date_1)

I replaced the real name of the field by “FIELD” for confidentiality reason.

So I don’t know how to investigate this further but it seems that there is an issue with dates.

_Originally posted by @ssougnez in https://github.com/oracle/dotnet-db-samples/issues/49#issuecomment-660342024_

[alexkeh]

This issue is resolved.

Explanation: If the EF Core model does not accurately indicate which string properties are and are not Unicode, performance can become significantly degraded, including queries undertaking full scans. When the provider scaffolds the model, this problem shouldn’t happen. When the mapping is manually created or the scaffolded model is modified, this performance problem may occur.

To avoid the problem, one can either:

• Use scaffolding to generate the entity classes corresponding to the database tables. The correct fluent API for each of the columns in the table will be generated.
• If manually creating the entity classes corresponding to the database tables, then correctly map each string entity property to the correct column type, especially when identifying whether the data type uses Unicode or not.

For example: By default, the .NET String entity type maps to Oracle NVARCHAR2. If the column type in the database is VARCHAR2, then the IsUnicode(false) or HasColumnType(“VARCHAR2”) fluent API should be used to correctly map the string entity property to VARCHAR2 database type.

[alexkeh]

No problem @ssougnez. Glad we could help.