fix(objectql): normalize OData $search/$searchFields so the search executor runs (ADR-0061)#2142
Merged
Merged
Conversation
…ecutor runs (ADR-0061) Follow-up to the $search executor (#2134): over the REST/OData path the term never reached engine.find(). protocol.findData() normalizes $-prefixed OData params ($top/$skip/$orderby/$select/$count) to bare names, but NOT $search / $searchFields — so `$search=retail` fell through to the implicit-field-filter pass and became `where.$search = 'retail'` (a non-existent column), which the driver silently returns [] for. The engine's expandSearchToFilter (which reads ast.search) therefore never fired. - Add ['$search','search'] and ['$searchFields','searchFields'] to the dollar→bare normalization, and add 'searchFields' to knownParams so the bare form isn't treated as an implicit filter. - Test: findData normalizes $search/$searchFields to bare and never leaks them into where. Verified end-to-end over the real HTTP API against a dev backend: searching "retail" returns the 3 retail-industry accounts (matched by the industry label→value), "technology" → 4, "Contoso" → 1 by name, "zzqq" → 0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 14 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
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
2 participants
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.
Follow-up to the
$searchexecutor (#2134). Browser/HTTP end-to-end testing revealed the executor never ran over the REST/OData path:protocol.findData()normalizes$-prefixed OData params ($top/$skip/$orderby/$select/$count) to bare names, but not$search/$searchFields. So$search=retailfell through to the implicit-field-filter pass and becamewhere.$search = 'retail'(a non-existent column) → the SQL driver silently returns[]. The engine'sexpandSearchToFilter(which readsast.search) therefore never fired —$searchlooked like a no-op over HTTP even though the engine logic was correct and unit-tested.Fix
['$search','search']and['$searchFields','searchFields']to the dollar→bare normalization loop infindData.'searchFields'toknownParamsso the bare form isn't swept into implicit filters.findDatanormalizes$search/$searchFieldsto baresearch/searchFieldsand never leaks them intowhere.Verification (real HTTP API, dev backend with the executor)
?$search=retail→ 3 retail-industry accounts (Acme Retail / Northwind / Wonka Brands), matched by the industry label→value, not by name.?$search=technology→ 4 (by industry label) ·?$search=Contoso→ 1 (by name) ·?$search=zzqq→ 0 · baseline → 13.This is the missing link that makes ADR-0061 P2 actually work end-to-end over REST. Unit tests: protocol-data (34) green; objectql typecheck clean.