[finding] 仓内存在 5 个独立的过滤器→谓词编译器,每次语义裁决成本 ×5 —— 值得立「谓词编译收敛」调查程序(#5298 成本清单副产品)

[os-zhuang]

#5298 第一棒成本清单(2026-08-06)的结构性副产品,按事实记录,unassigned、交分诊定级。维护者在 PM 会话确认「值得记账」。

事实

同一个 FilterCondition 语义,今天由 5 个互不继承的编译/求值器各自实现:

#	面	位置	服务的读路径
1	driver-sql(+wasm/turso-local 继承)	sql-driver.ts	CRUD
2	turso RemoteTransport	remote-transport.ts buildWhereSQL	CRUD(remote 模式)
3	service-analytics read-scope-sql	read-scope-sql.ts	RLS 读侧(analytics)
4	service-analytics filter-normalizer	filter-normalizer.ts	Cube/dashboard
5	formula matchesFilterCondition	matches-filter.ts	RLS 写侧 check / 内存求值

(第六个半:objectql having-filter.ts,见 #5905。driver-memory/mongodb 另有各自实现,现冻结。)

为什么是结构性问题

• 每次语义裁决的实施成本 ×5:$not 的语义在 driver-sql 与 driver-memory / formula 之间分叉：NULL 行的去留相反，$not: {} 一个是 TRUE 一个是 FALSE #5146($not NULL-safe)当时漏了面 2 → 变成 drivers(turso): remote 模式没有继承 #5146 的 $not NULL-safe —— 同一个 TursoDriver,local 返回 NULL 行、remote 不返回(实测,origin/main) #5903;非否定路径上的 $ne / $nin / $notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了 $not) #5298(非否定 NULL-safe)要动 1/3/4,2 并入 drivers(turso): remote 模式没有继承 #5146 的 $not NULL-safe —— 同一个 TursoDriver,local 返回 NULL 行、remote 不返回(实测,origin/main) #5903;fix(service-analytics): read scope 的 { $not: {} } 不再整表放行,$not 改为 NULL-safe (#5297) #5326/fix(service-analytics)!: 作者的 where 也 NULL-safe —— $not 下推守卫、{$not:{}} 为零行、{} 析取项吸收 $or (#5325) #5335 各花一轮把 3/4 对齐 $not——同一支税反复交。
• AI 防错角度:规则作者(人或 AI)不可见自己的过滤器会落进哪个编译器,per-面差异对作者不可学习;每个新面都是分叉的新藏身处。
• 现有缓解(FILTER_LOGIC_CASES 共享表)只覆盖已入表格位,且 harness 接入是 11 处手工重复。

建议方向(不代裁决,供调查程序评估)

• 谓词下译层收敛:提取共享的 filter→SQL-AST lowering(面 1/2/3 的公共前段),方言只做最后一寸;
• 或最低限度:把「新语义裁决必须逐面清单化」写进流程门禁(裁决模板带面清单,非否定路径上的 $ne / $nin / $notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了 $not) #5298 的 §1 可作模板)。

关联:#5298(成本清单 §1)、#5903、#5905、#5146、#5326、#5335、#5239/#5240。

[claude]

发现分诊轮:持有(留 finding),补域 domain:engine-core。

• 过时前提检查:五个编译面(driver-sql / turso buildWhereSQL / read-scope-sql / filter-normalizer / formula matches-filter)与第六个半(objectql having-filter,见 objectql having-filter.ts 是「无值字段」语义的第五个求值面,且带着 #5299 同款的早退守卫($nin / $notContains 不在豁免名单) #5905)在 origin/main 上现状不变;driver-memory / driver-mongodb 两族按维护者 2026-08-05 冻结指令(锚点 [裁决] driver-memory / driver-mongodb 投入冻结 —— 维护者 2026-08-05 口径（跨单锚点） #5499)本就不在收敛范围内。前提成立。
• 为什么持有而不晋级:本单要的是一个调查/收敛程序(跨 drivers / services / formula 三个域、多周量级),不是一个有落点的缺陷;直接 pm:queue 会让某个车道认领一个它无权决定范围的重构。晋级路径是先取维护者 appetite(转 needs-user-decision 的程序卡),不是直接派发。
• 重启条件:①再出现一次「同一语义裁决要分别改 ≥3 个面」的实施单($not 的语义在 driver-sql 与 driver-memory / formula 之间分叉：NULL 行的去留相反，$not: {} 一个是 TRUE 一个是 FALSE #5146→drivers(turso): remote 模式没有继承 #5146 的 $not NULL-safe —— 同一个 TursoDriver,local 返回 NULL 行、remote 不返回(实测,origin/main) #5903、非否定路径上的 $ne / $nin / $notContains:driver-sql 排除 NULL 行,driver-memory / formula 返回它们(#5146 只裁定了 $not) #5298、fix(service-analytics): read scope 的 { $not: {} } 不再整表放行,$not 改为 NULL-safe (#5297) #5326/fix(service-analytics)!: 作者的 where 也 NULL-safe —— $not 下推守卫、{$not:{}} 为零行、{} 析取项吸收 $or (#5325) #5335 已是三次),或②维护者给出收敛程序的 appetite —— 届时由分诊座位转决策箱立卡。
• 域:domain:engine-core —— 语义权威面是 packages/formula 的 matches-filter(RLS 写侧 check),objectql having-filter(objectql having-filter.ts 是「无值字段」语义的第五个求值面,且带着 #5299 同款的早退守卫($nin / $notContains 不在豁免名单) #5905)同座位;analytics 两面属 services、sql 面属 drivers,任何收敛程序都从 engine-core 的语义定义出发。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-zhuang]

清点订正(来自 PR #6004 / #5977 的实测,不扩本单范围、不改标签、不构成认领):Cube 面是 2 个发射器,不是 1 个。

#5298 成本清单 §1.C 把「独立发射器」记为 3 个,其中 Cube 面指向 strategies/filter-normalizer.ts:267-275。实测(#5977 第二批)证明那处是 MONGO_TO_CUBE_OP 算子改名表,本身不决定 NULL 行为;真正把 normalized 树编译成谓词的是两个互相独立的实现:

#	位置	产物
1	strategies/native-sql-strategy.ts buildFilterClause	真正执行的原生 SQL
2	strategies/objectql-strategy.ts buildFilterClauseSql(经 renderFilterNodeSql)	/analytics/sql 回显语句
3	strategies/objectql-strategy.ts filterNodeToCondition	交给 ObjectQL 引擎的 FilterCondition(再由 driver 编译第三次)

其中 1 和 2 各自持有一份算子→SQL 表(opMap/likeShape 与 SCALAR_SQL_OPS/LIKE_SQL_OPS),文件里明写「deliberately the same pair of tables」——即刻意的手抄副本,正是本单描述的成本形状。

改前实测三者对 {stage: {$ne: 'won'}} 给出 2 / 2 / 2,3,4 三个答案里的两种,且第 3 列之所以对,只是因为 #5962 让下游 driver-sql 自己加了守卫,而不是 analytics 层做对了。

对本单的意义:全仓口径应从「5 个编译器」修正为更高——按语义裁决的实际支付面算,#5298 这一条裁决在 analytics 一个包内就付了 2 次(若含引擎那次转译则 3 次)。另外值得记的是 #5977 的解法本身是本单方向的一个小样本验证:把守卫下沉成树结构(而非各 strategy 各写一遍 SQL 技巧)后,3 个消费者零改动地同时对齐 —— 收敛点未必是「合并编译器」,也可以是「把语义留在共享的中间表示里,让编译器只管方言」。

会话:session_01WyvqvKMG6asi9aXjKE6xtx

---

Generated by Claude Code