CODEWITHSUNDEEP
c#entity-framework.net-coreentity-framework-core
Matthias
Matthias

Reputation: 1437

EF Core: Any reason to not throw on QueryClientEvaluationWarning

EF Core has a feature where it can evaluate parts of an query in memory when this part can not be executed on the DB. It logs a warning when this happens.

Optionally EF Core can be configured to throw an exception when that happens

optionsBuilder
    .UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EFQuerying;Trusted_Connection=True;")
    .ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning)); // <--

Since evaluating something in memory that the programmer intended to be executed in the DB can be a huge performance issue and is somewhat unclean imho I'm now thinking about using this exception configuration just everywhere and all the time.

I'm just wondering if there are any good reasons to not throw an exception? I personally would prefer an exception and then change the code to be executed intentionally in memory (e.g. with a .ToList() before the problematic statement). It's strange to me that EF would just work around a design flaw like that.

However I'm unsure if I'm forgetting any good reason why this exists in the first place or any situation where this might be necessary.

Upvotes: 6

Views: 4406

Answers (1)

Nick
Nick

Reputation: 5042

A good reason to not throw an exception is when you use a non-relational database and where you would have to do data processing and searching in your code. Another case can be if you use a linq query to combine data from multiple sources - in-memory data structure, XML, database, and you expect that you will only read from these sources and do all the processing in your code.

When you target relational databases only, however, you should always throw.

Upvotes: 5

Related Questions