Repository navigation
fix: let a query filter order the context's own values without a lambda - #234
Open
CaffeinatedCoder wants to merge 3 commits into
Open
CaffeinatedCoder wants to merge 3 commits into
CaffeinatedCoder wants to merge 3 commits into
Conversation
HasQueryFilter(r => r.Rank == Limits.Max()) over a value object whose ordering is its own CompareTo was refused when the model was built, though EF evaluates Limits.Max() in memory, by CompareTo, and sends the answer as one parameter. The Finder refused an ordering operator in a filter without asking whether it runs in memory, as its comparison branches do. It now lets an ordering through in a filter when it reads nothing of the database and takes no lambda. The lambda matters: measured on SQLite, EF evaluates Limits.Max(), Min(), Order().First() and OrderDescending() .First() in memory, but sends the values to the database and orders them there for OrderByDescending(l => l).First(), which kept the row ranked 3 where memory keeps 1, and fails to translate MaxBy(l => l). So #225's proposed change, skipping by database reads alone, would have answered those silently; they stay refused. KB-058 pins the distinction with plain EF (a collection with a lambda goes into the SQL as a VALUES list of parameters; Max(v => v) throws inside EF). The README says when a filter may order the context's values (claim E05-query-filter-own-values). Input class (EFT): an ordering operator in a query filter, by its source: the context's values without a lambda (allowed: Max, Min, Order().First(), OrderDescending().First() over an array and a list), the context's values with a lambda (refused: OrderByDescending(l => l), MaxBy, a boxing Select before Max, which EF happens to evaluate but which the lambda rule keeps refused), the entity's navigation and the table itself (refused). Reverting the source fails the 4 allowed rows; dropping the lambda condition, the change #225 proposed, fails the 3 refused ones. Refs #225 Defect-Class: EFT Found-By: OR Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CaffeinatedCoder
added
bug
Base automatically changed from
fix/ef-boxed-ordering-refused-2-3-1
to
release/2.3.1
October 31, 2026 07:48
CaffeinatedCoder
removed
the
stacked
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…r-captured-ordering-2-3-1 # Conflicts: # CHANGELOG.md # design/knowledge/README.md
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #225
Stacked on #217 (
fix/ef-boxed-ordering-refused-2-3-1): both changeHandWrittenOrderingInterceptor'sFinder. Merge #217 first, then retarget this PR torelease/2.3.1.Problem
HasQueryFilter(r => r.Rank == Limits.Max())over a value object whose ordering is its ownCompareTowas refused when the model was built, though EF evaluatesLimits.Max()in memory byCompareTo. TheFinderrefused an ordering in a filter without asking whether it runs in memory. But the issue's proposed fix (skip whatever reads nothing of the database) is wrong for half the shapes: measured on SQLite, EF sends the context's values to the database and orders them there when the chain takes a lambda.Limits.OrderByDescending(l => l).First()kept the row ranked 3 where memory keeps 1.Change
An ordering in a filter is let through when it reads nothing of the database and takes no lambda (
OrderingRunsInMemory). New verified fact KB-058, with an executable test on plain EF: a lambda-free chain over captured values becomes one scalar parameter, and a chain with a lambda puts the values in the SQL (aVALUESlist of parameters in EF 10). The EF Core README says when a filter may order the context's values (claimE05-query-filter-own-values); there's a changelog line under 2.3.1.Tests
Max(),Min(),Order().First(),OrderDescending().First()over an array and a list.OrderByDescending(l => l).First(),MaxBy(l => l),Select(l => (object)l).Max()(which EF happens to evaluate, but the lambda rule keeps it refused, the loud side), and an ordering of the table itself (Set<T>().Max(...)).KB058green.🤖 Generated with Claude Code