EF Core: a query filter that orders a value object by Min, Max or Order over the context's own values is refused, although EF runs it in memory #225

Reported by an external review of release/2.3.1 @ dbdd44e, which reproduced it; the cause confirmed here by reading the source, not yet run.

Package

CodoMetis.TypeKit.EntityFrameworkCore

Version

2.3.0 (the same code in v2.3.0), and release/2.3.1 @ dbdd44e

How does it fail?

Loudly. A valid query filter is refused at model building

Problem

HandWrittenOrdering.Finder.VisitMethodCall (src/CodoMetis.TypeKit.EntityFrameworkCore/HandWrittenOrderingInterceptor.cs:113) refuses a Queryable or Enumerable ordering operator (Min, Max, Order, OrderBy, MinBy, ...) without asking RunsInMemory (:173). The comparison branches above and below it do ask. In a query filter (RefuseInFilter, skipsWhatRunsInMemory: true), an operator over the context's own values reads nothing of the database: EF evaluates it in memory, by the value object's CompareTo, exactly as the filter's documented skip intends. It is refused all the same.

Scenario

ProbeDescending (hand-written descending CompareTo), Limits a ProbeDescending[] held by the context:

modelBuilder.Entity<Ranked>().HasQueryFilter(r => r.Rank == Limits.Max());
// InvalidOperationException: ProbeDescending is ordered by Max in the query filter of Ranked ...
// expected: no refusal; EF evaluates Limits.Max() in memory, by CompareTo

The query path (RefuseIn) is not affected: EF has already evaluated the captured part there.

Change

Guard the ordering branch with !RunsInMemory(node), as the CompareTo and binary branches are, so an operator whose source reads no entity and no DbSet passes; one over the entity's navigation or a DbSet is still refused.

Test

A row in the query-filter theory of HandWrittenOrderingTests for each of Max, Min, Order, OrderBy(x => x) and MaxBy over a captured array and a captured list, accepted, beside the existing refused rows over the entity; reverted per verify-the-guard. Input class: an ordering operator in a query filter, by its source (captured, the entity's navigation, a DbSet), against QueryShapes. Land after #217, which changes the same branch.

Environment

.NET SDK 10.0.4xx, EF Core 10; any provider.

Measured: the change above is half wrong; fixed in #234 (52572fb)

Measured on SQLite at 8562de6: EF evaluates an ordering over the context's values in memory only when the chain takes no lambda (Max(), Min(), Order().First(), OrderDescending().First()). With a lambda it sends the values to the database and orders them there: LimitList.OrderByDescending(l => l).First() kept the row ranked 3 where memory keeps 1, and MaxBy(l => l) fails translation. So guarding by RunsInMemory alone would have made those silent. #234 lets an ordering through only when it reads nothing of the database and takes no lambda; the lambda shapes stay refused (Select(l => (object)l).Max() too, which EF happens to evaluate). Verified fact KB-058 pins the distinction on plain EF.