Filed by the domain:ui execution seat (session session_01EMrWaQw3XS5DxTHxp4yRyC) out of the review of PR #7377 (#7349), so the decision taken there is visible to a query instead of living in a PR body and a default arm.
Dedupe: semantic search for the in-memory matcher not implementing like / ilike returns only #7379 (a different operator defect — contains executing icontains semantics) and #7349 itself; control query on the same endpoint fires with 4 hits including #7349, #6948 and #4744. No card names this.
The state
like and ilike are members of the spec's published AST operator vocabulary. They survive canonicalisation as themselves, pinned in the spec's own suite:
packages/spec/src/data/filter-like-wire-lowering.test.ts:146
expect(canonicalAstOperator('like')).toBe('like');
expect(canonicalAstOperator('ilike')).toBe('ilike');
expect(canonicalAstOperator('like')).not.toBe(canonicalAstOperator('contains'));
@object-ui/core's ValueDataSource.matchesASTFilter does not implement them. It has no pattern engine.
⚠️This is not a regression introduced by PR #7377, and reading it as one would be wrong. The matcher never implemented them. What #7377 changed is the failure mode:
| before #7377 | after #7377 |
|---|
authored ['role', 'like', '%admin%'] | matched every row, silently | matches no row, with one console.warn naming the operator |
Both answers are wrong; the second one says so. The gap between "the spec declares it" and "this consumer executes it" is unchanged and pre-existing.
Why it was left refused rather than implemented
Ruled by the seat on #7349 (comment 5511900935), as open question 2 of that dispatch, recommendation A from the implementing lane and accepted:
- Zero measured pull. No producer in this repo emits
like or ilike into a filter. The card that would justify implementing them does not exist yet. - The spec already exports
matchesLikePattern, so the day a producer appears the implementation is a small, well-defined piece of work — declining now costs almost nothing later. - The refusal is loud. A silent wrong answer needs someone to notice a result set is too large; a refusal names the operator in the console and returns an empty set, so the first producer to emit one surfaces the gap by itself.
- Startup scope discipline: implementing a published-but-unconsumed operator is speculative surface.
What would change the answer
Any producer emitting like or ilike into a $filter that can reach a provider: 'value' data source. At that point this stops being an observation and becomes a defect with a user behind it, and the repair is bounded: canonicalise as today, add two arms backed by the spec's matchesLikePattern, pin both against the wire-side lowering.
⛔ Deliberately not proposed here: implementing them now. That is the decision already taken; this card exists so the decision is findable, and so a future producer has somewhere to land.
Refs: #7349 / PR #7377 (where the refusal arm landed and this was ruled) · #7379 (the sibling operator defect in the same switch — contains computing icontains) · #7380 (the constructor's JSON round-trip, same file).
Filed by the
domain:uiexecution seat (sessionsession_01EMrWaQw3XS5DxTHxp4yRyC) out of the review of PR #7377 (#7349), so the decision taken there is visible to a query instead of living in a PR body and adefaultarm.Dedupe: semantic search for the in-memory matcher not implementing
like/ilikereturns only #7379 (a different operator defect —containsexecutingicontainssemantics) and #7349 itself; control query on the same endpoint fires with 4 hits including #7349, #6948 and #4744. No card names this.The state
likeandilikeare members of the spec's published AST operator vocabulary. They survive canonicalisation as themselves, pinned in the spec's own suite:@object-ui/core'sValueDataSource.matchesASTFilterdoes not implement them. It has no pattern engine.['role', 'like', '%admin%']console.warnnaming the operatorBoth answers are wrong; the second one says so. The gap between "the spec declares it" and "this consumer executes it" is unchanged and pre-existing.
Why it was left refused rather than implemented
Ruled by the seat on #7349 (comment 5511900935), as open question 2 of that dispatch, recommendation A from the implementing lane and accepted:
likeorilikeinto a filter. The card that would justify implementing them does not exist yet.matchesLikePattern, so the day a producer appears the implementation is a small, well-defined piece of work — declining now costs almost nothing later.What would change the answer
Any producer emitting
likeorilikeinto a$filterthat can reach aprovider: 'value'data source. At that point this stops being an observation and becomes a defect with a user behind it, and the repair is bounded: canonicalise as today, add two arms backed by the spec'smatchesLikePattern, pin both against the wire-side lowering.⛔ Deliberately not proposed here: implementing them now. That is the decision already taken; this card exists so the decision is findable, and so a future producer has somewhere to land.
Refs: #7349 / PR #7377 (where the refusal arm landed and this was ruled) · #7379 (the sibling operator defect in the same switch —
containscomputingicontains) · #7380 (the constructor's JSON round-trip, same file).