Repository navigation
10.x: RangeLowerBoundComparer.Compare in a query runs in the range order (port of #385) #396
Description
Problem
The same defect as #385, on release/10.x. RangeLowerBoundComparer<TRange, T>.Instance.Compare(a, b) (and RangeSet<TRange, T>.LowerBoundComparer, the same instance) runs as SQL in the range order inside an EF Core query, because EF Core rewrites any Compare(a, b) to the natural comparison (dotnet/efcore#39402). A filter selects different rows than the same LINQ over the loaded rows, without an error.
Measured 2026-10-24 on release/10.x (9af5842), PostgreSQL 16, on EF Core 10.0.0 and on 10.0.13 with Npgsql 10.0.3, with p = [2026-03-01,2026-03-10]:
| Row | Period |
Memory | SQL |
|---|---|---|---|
| 1 | [2026-03-01,2026-03-10] |
0 | 0 |
| 2 | [2026-03-01,) |
0 | 1 |
| 3 | [2026-03-01,2026-03-03] |
0 | -1 |
| 4 | [2026-03-05,2026-03-06] |
1 | 1 |
Where(r => comparer.Compare(r.Period, p) == 0) becomes WHERE r."Period" = @p and selects row 1, where memory selects rows 1, 2 and 3. The same through IComparer<DateRange>. Identical to main.
Change
Port whichever fix #385 lands on main (refuse or translate), with a regression test of its own. Remove the known-difference entry from docs/efcore.md#what-runs-where that 10.2.0 adds (#397).
Release
silent: one row under ### Changed answers in the 10.x minor it ships in. Fixed only on release/10.x, so close it by hand.
Activity
CaffeinatedCoder commentedon Oct 25, 2026
Scheduled for 10.3.0 (#408), on condition that the
mainfix lands first. Otherwise it moves to the next 10.x minor.CaffeinatedCoder commentedon Oct 25, 2026
#385 is fixed on
main(PR #444, merged) by refusing the call. The port is PR #446 againstrelease/10.x, stacked on the #395 port (#445) because both add rows at the same places in the changelogs anddocs/migration.md. AnyIComparerover a range or set,RangeSet.LowerBoundComparerandComparer<T>.Defaultincluded, now runs in memory only in a query: a filter or an ordering fails translation, and a finalSelectruns the comparer on the loaded rows.LowerBoundComparerQueryTestsis this line's regression test; the #396 candidate is removed, and Known differences in 10.2.0 now says 10.3.0 fixes both entries. Full 10.x integration suite passes on PostgreSQL 16 (304). Close this by hand once #446 merges.Merge pull request #446 from CaffeinatedCoder/fix/396-lower-bound-com…
CaffeinatedCoder commentedon Oct 25, 2026
Fixed on
release/10.xby PR #446 (merged as a8ad482), shipping in 10.3.0. Closed by hand, sinceCloses #nacts only onmain.