Repository navigation
finding(core): like / ilike are spec-valid AST operators that ValueDataSource's in-memory matcher does not implement — now refused loudly instead of matching every row #7383
Description
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.
| 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
likeorilikeinto 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).
Activity
os-zhuang commentedon Sep 5, 2026
分诊 —
domain:ui/priority:p3/pm:on-hold/finding锚定 (anchoring)：若将来实现，落在
packages/core/src/adapters/ValueDataSource.ts⇒domain:ui。为什么是
pm:on-hold而不是pm:queue⭐ 这张卡不是待办，是一份决定记录。 卡片自己说得最清楚：
决定已在 #7349 的调度中裁过（seat comment
5511900935，open question 2，采纳实现车道的推荐 A）。把它放进pm:queue会让某个执行席以为该动手，而动手恰恰违背已有裁决。pm:on-hold是它正确的位置。Restart-when（卡片自己给的判据，本席原样采纳并写成可查形式）：
在
origin/maina472b07上复核 —— 与卡片一致ValueDataSource.ts里 没有'like'/'ilike'的 case，也没有matchesLikePattern—— 匹配器确实不实现它们，两个 operator 落进 #7377 装的通用拒绝路径：拒绝机制在，且是"收集 refusals 后逐条 warn"的形状 —— 与卡片描述的"匹配无行 + 一条点名 operator 的
console.warn"一致。⭐ 卡片最该被保留的一段：它自己拦住了一个误读
['role', 'like', '%admin%']两个答案都不对，但第二个会说话。⛔ 未来任何人看到"like 过滤返回空"，不要把它当成 #7377 引入的回归 —— 那会导致有人去"修好"这个拒绝臂，把一个响亮的错误换回一个静默的错误。这段话是本卡最有价值的部分。
定级理由
priority:p3：like/ilike。matchesLikePattern，来了生产者就是加两个臂 + 对着 wire 侧 lowering 钉住。不关闭：卡片存在的目的是让这个决定可被查询到，而不是活在一个 PR body 和一个
default臂里。这是正当的用法。⛔ 给未来接手者的边界
matchesLikePattern支撑的臂 ⊕ 对着 wire 侧 lowering 双向钉住。⛔ 不要自己写模式引擎。ValueDataSource'scontainsis case-INSENSITIVE, so it executesicontainssemantics — the spec keeps the two operators deliberately distinct #7379（contains执行icontains语义 —— 且本席测出四个臂都大小写不敏感，不止一个）和 finding(core):ValueDataSource's JSON deep-clone rewrites the data it stores —NaNbecomesnull,undefinedkeys vanish,Datebecomes a string #7380（构造器的 JSON 往返 —— 且本席测出出口:587也有一处）。三张卡都在这个 switch 及其邻近，合并成一次"把ValueDataSource的 operator 语义与 spec 对齐"的工作可能比分三次便宜。⛔ 但那是执行席的判断，本席不代并。⛔ 分诊席不认领、不派单、不写码、不推翻 #7349 的裁决。
Generated by Claude Code
objectstack-fleet commentedon Sep 24, 2026
关闭
not_planned—— 维护者同意:这是一份"暂不实现"的决定记录;明确的警告就是提醒,第一个真正用到的人会立刻看到分诊席(
session_01Tw7jnJinGHvoGSi8aFkhPJ,objectstack 座位贴 #6015),2026-09-24T15:03Z。objectui 清理第十批(#8587 的挂起卡一次性清点):本席读完了卡面和评论(1 条,全部读到),并在本地 main(62597c5)上跑了重启条件的探测命令,把建议报给维护者。维护者答:「其他同意」。本卡说的是什么
like/ilike是 spec 发布的操作符,但@object-ui/core的ValueDataSource内存匹配器没有实现它们。PR #7377 之后,遇到它们会返回空结果并打印一条点名该操作符的console.warn(以前是悄悄返回所有行)。#7349 已裁定:没有使用方之前不实现。本席实测(本地 main
62597c5)ValueDataSource.ts:1107的拒绝警告仍在。query-ast.ts:143-144、view-config-utils.ts:94把like折成contains、data-protocol.ts的类型联合),没有任何代码往provider: 'value'的数据源发like/ilike。⇒ 重启条件没有触发。为什么关
决定早已做出,关闭后记录仍可搜到。明确的警告本身就会让第一个使用方发现这个缺口,继续挂着没有额外价值。
什么时候重开
真的有功能往⚠️ 同一文件还有 #7379、#7380 两张同族卡,动手时一起看。
provider: 'value'的数据源发like/ilike时。修法已知且小:照现在的方式规范化,加两个由 spec 导出的matchesLikePattern支撑的分支,并对照 wire 侧的写法双向钉住。⛔ 不要自己写模式匹配引擎。标签:摘
pm:on-hold;以not_planned关闭。Generated by Claude Code