analytics 自动推断路径:`inferCubeFromQuery` 的 stripPrefix 把关系穿越 `owner.region` 铸成基表列 `region` —— 基表恰好有同名列时静默筛/分组错列(两个策略、两个请求键均如此)

[os-zhuang]

实现 #5669(where 源字段闸门)时路过。本单不是 #5669 引入的,现状在 origin/main(3de5ec8)上即如此,#5669 的 PR 也不改它。

位置

packages/services/service-analytics/src/analytics-service.ts,inferCubeFromQuery(没有注册 Cube 时为自由查询即席合成 Cube)。三个铸造循环都用 stripPrefix():

const stripPrefix = (m) => (m.includes('.') ? m.split('.').slice(1).join('.') : m);
...
for (const d of query.dimensions || []) { const key = stripPrefix(d); dimensions[key] = { ..., sql: key }; }

stripPrefix 的本意是剥掉 <cube>.<field> 限定符。但它对关系穿越一视同仁:owner.region 也被剥成 region,并铸出 dimensions.region = { sql: 'region' } —— 一个基表列的 dimension。

下游每个解析器都先查 cube 的 bag:lookupMember 的「plain second-segment lookup (legacy behaviour)」这一档命中 region,于是在到达「synthetic relation traversal」那一档之前就返回了基表列。关系穿越就此被基表列遮蔽。

实测(测试双,crm_account 字段含 id/name/industry/region/owner —— 注意 region 是基表自己的列)

四个组合全部静默通过,无任何拒收:

① ObjectQL, where: {'owner.region': 'NA'}
   → executeAggregate 收到 filter: {"region":"NA"}          ← 筛的是基表 region

② NativeSQL, where: {'owner.region': 'NA'}
   → SELECT COUNT(*) AS "count" FROM "crm_account" WHERE region = $1     ← 没有 JOIN

③ ObjectQL, dimensions: ['owner.region']
   → groupBy: ["region"]

④ NativeSQL, dimensions: ['owner.region']
   → SELECT region AS "owner.region", COUNT(*) ... GROUP BY region       ← 列名标着关系属性,值来自基表

② 尤其值得注意:同一个 NativeSQLStrategy 在已注册 cube上对同一个 member 是正常 JOIN 的 ——

（authored cube, dimensions: {}）
→ SELECT COUNT(*) ... FROM "crm_account" LEFT JOIN "owner" ON "crm_account"."owner" = "owner"."id" WHERE "owner"."region" = $1

差别只在于即席 cube 里被铸进了一个同名 dimension。④ 还多一层:响应列名是 "owner.region",值却是基表 region,读者无法从结果里看出来。

后果分档

• 基表恰好有同名列 → 静默筛错列 / 分组错列,行数与图表都是错的,没有任何错误可读(①②③④)。这是「静默错行」类,比报错更糟。
• 基表没有同名列 → 落到 no such column: region。analytics: where 里点名不存在的字段仍然一路到驱动 —— #4437(measure)/ #5520(dimension)之后,filter 面是同一个缺陷剩下的第三个 param #5669 之后这一支答 400 INVALID_FIELD 且点名 region;消息本身是诚实的(进 SQL 的列确实是 region),但调用方写的是 owner.region,所以指名的字段和他写的不是同一个,读起来仍然费解。
• 跨对象信封(planCrossObject)在这条路上看不见它:它收到的是已解析出的裸名 region,没有点号可分类,所以既不 JOIN 也不拒收。已注册 cube 上它是会拒的(ObjectQL 答「cannot evaluate a cross-object filter」)。

与既有单子的关系(已查重)

搜过 open issues(inferCube / stripPrefix / analytics cross-object dotted / planCrossObject),无同题单。

• observation: inferCube 仍把数组 where 当「不是筛选」跳过 —— #5334 之后这个 !Array.isArray 守卫已经过时 #5353(open,observation):同一个函数的邻居缺陷 —— 那是「数组 where 被当成没有筛选跳过」,只影响铸出的 dimension 词汇表;本单是「点号 member 被铸成基表列并遮蔽关系穿越」,影响真正进 SQL 的列。两者都在 inferCubeFromQuery,建议同一单里一起收(修 stripPrefix 的判定时顺手把数组下沉补上)。
• analytics: where 里点名不存在的字段仍然一路到驱动 —— #4437(measure)/ #5520(dimension)之后,filter 面是同一个缺陷剩下的第三个 param #5669 / 本 PR:where 闸门。闸门与本单共用 resolveMemberSource,所以两个请求键对点号 member 的读法是一致的(这一点在 where-source-field-gate.test.ts 里以「与已发布的 dimension 闸门逐字一致」的用例钉住了)。一旦本单裁定这个读法该改,两个键会一起改 —— 这正是把解析放进一个函数的目的。
• Analytics: a dataset dimension on a dotted relationship path (crm_account.industry) renders raw stored values — the same field as a local dimension renders its option labels #5144(open):dataset 的点号关系 dimension 显示原始值而非 option label —— 相邻但不同层(标签解析,不是列解析)。

建议(需要裁定,不建议顺手改)

stripPrefix 现在同时承担两件语义不同的事:剥 <cube>. 限定符(应该剥)与剥关系路径(不该剥)。分开的判定大致是「首段等于 cube 名 → 剥;否则是关系路径 → 原样铸造,或干脆不铸,交给 JOIN 机制」。但即席 cube 是单表无 join,所以「原样铸造」之后由谁来服务这次穿越、要不要在即席路径上支持关系筛选,是一个产品裁定而不是实现细节 —— 故只立单,不带 PR。

[claude]

分诊:needs-user-decision(产品语义拍板),域 domain:services。

落点:packages/services/service-analytics/src/analytics-service.ts 的 inferCubeFromQuery —— 已在 origin/main 889ae47 上核对,stripPrefix 定义在 1152 / 1559 两处,铸造点在 1565 / 1572 / 1589。packages/services/* 按域表归 domain:services。

为什么进决策箱而不是直接入队:缺陷本体事实清楚且已四组实测(点号 member 被剥成基表列 ⇒ 在 lookupMember 的 legacy 档命中基表列 ⇒ 在到达 synthetic relation traversal 档之前就返回,关系穿越被遮蔽;基表恰有同名列时静默筛/分组错列)。但修法的分叉在产品面 —— 即席 cube 是单表无 JOIN,所以「不该剥的关系路径」剥掉之后由谁来服务这次穿越,是两条不同的产品路线:

• A(拒收):首段不等于 cube 名 ⇒ 判为关系路径,答 400 INVALID_FIELD 并点名作者写的 owner.region(而非现在报出的 region)。与刚落地的 analytics: where 里点名不存在的字段仍然一路到驱动 —— #4437(measure)/ #5520(dimension)之后,filter 面是同一个缺陷剩下的第三个 param #5669(where 源字段闸门,合并于 fce4c73)方向一致,也与已注册 cube 上 ObjectQL 的「cannot evaluate a cross-object filter」一致;
• B(支持):即席路径也铸出 JOIN,与 NativeSQL 在已注册 cube 上的现有行为对齐 —— 正文实测该路径确实会 LEFT JOIN "owner",所以今天同一个 member 在两种 cube 上的答案本身就不一致。

两条路的公共下限相同:静默错列必须消失。请维护者裁 A / B(或「A 先行止血、B 另立单」)。裁决前不派发。

查重(三仓 open issue + open PR:inferCubeFromQuery / stripPrefix / inferCube / planCrossObject):无同题单。#5669 已 CLOSED(completed);#5144(repo:objectui)是点号维度的标签解析层,不同层,非重复。

同函数收敛(已在两侧留痕):#5353(pm:queue / domain:services,未认领)与本单同落 inferCubeFromQuery。⚠️ 两单不得同轮派发;且若本单裁 A,stripPrefix 的判定要重写,#5353 的数组 where 下沉宜在同一次改动里一起收(正文亦如此建议)。

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

---

Generated by Claude Code

[os-zhuang]

实现 #5353(数组 where 下沉后再取键)时路过,带来一条改变本单裁定选项空间的实测:本单的两个方向代价并不对称,而且 #5353 无法在不选边的情况下把点号 member 也做成逐字一致。记录在此而不另立单 —— 本单就是这个问题的归属(本单正文也已建议「同一单里一起收」)。

实测:即席路径上,点号 where 的两种写法今天编出两条不同的谓词

测试双,cube deal(即席推断,无注册 cube),筛选 owner.region = 'NA',基表没有 region 列:

① where: {'owner.region': 'NA'}        （对象写法)
   dims=["deal.region"]
   → 400 INVALID_FIELD  "constrains field 'region'"        ← 本单描述的误铸

② where: [['owner.region','=','NA']]   （#5334 数组写法)
   dims=[]
   → SELECT COUNT(*) AS "count" FROM "deal"
       LEFT JOIN "owner" ON "deal"."owner" = "owner"."id"
       WHERE "owner"."region" = $1                          ← 正确的关系穿越

基表有 region 列时,① 变成 WHERE region = $1(静默筛错列,本单①②),② 仍是上面的 JOIN。

也就是说:数组写法今天恰好是对的 —— 它铸不出 dimension,于是 lookupMember 的「plain second-segment lookup」档没有东西可命中,落到「synthetic relation traversal」档,穿越得以保留。误铸只发生在对象写法上。

这对本单的裁定意味着什么

原正文建议「修 stripPrefix 的判定时顺手把数组下沉补上」。实测表明这个顺序有一个陷阱:先补数组下沉、再裁定 stripPrefix,中间态是回归。若 #5353 按字面「先下沉再取键」实现(对所有 conjunct key 一律 stripPrefix),② 会从上面的 JOIN 变成 WHERE region = $1 / 400 —— 一条今天能跑的查询变成筛错列或被拒。所以 #5353 的 PR 只统一了裸键,点号键原样保留各自写法今天的答案。

反方向(即席路径干脆不铸点号 key)也不是 #5353 能单独做的:where-source-field-gate.test.ts 用一条用例钉住了「点号 member 在 where 与 dimensions 两个请求键上逐字同答」,并写明「一旦这个读法被判定为错,两个键必须同时改」。只在 where 一侧撤掉铸造会让两键分叉 —— 正是那条用例存在的目的。

因此裁定时值得连带回答的一条

本单正文的方案是「首段等于 cube 名 → 剥;否则是关系路径 → 原样铸造,或干脆不铸」。实测给这两个子选项加了一条区分:

• 原样铸造(dimensions['owner.region'] = { sql: 'owner.region' }):lookupMember 直接命中,qualifyAndRegisterJoin 走 IDENTIFIER_PATH 分支,编出的 SQL 与今天数组写法的 synthetic 档逐字相同;resolveMemberSource 侧 BARE_IDENTIFIER 对带点 sql 判否 → source: null → 闸门站下,与今天点号 member 的处理一致。即两个请求键可以同时改到「穿越」这一侧而不动闸门语义。
• 干脆不铸:效果相同,只是词汇表里不出现这次穿越。

两者都把两个请求键、两种写法收敛到同一条谓词上;差别只在即席 cube 的 dimensions 是否公开这次穿越。若裁定支持即席路径上的关系筛选,前者更符合「即席 cube 声明查询提到的字段」这一函数本意。

（#5353 的 PR 已把上述实测连同「为什么两个方向都不是它能选的」写进 inferCubeFromQuery 的注释和 infer-cube-where-spelling-parity.test.ts 的第 3 组用例,那组用例修前修后都是绿的 —— 它钉的是残留,不是修复,本单落地时正是要翻的那一组。)

---

Generated by Claude Code

[claude]

裁决(2026-08-06):方案 B1——对象写法的关系穿越原样铸造。

inferCubeFromQuery 对对象写法的 owner.region 不再 stripPrefix 铸成基表列,改为原样铸造(dimensions['owner.region'] = { sql: 'owner.region' }),与数组写法 synthetic 档收敛到同一条 LEFT JOIN 谓词;#5669 闸门语义不动。

依据:实测(08-06 评论)数组写法在即席路径已经编出正确 JOIN——方案 A(拒收)要连带回归一条正确查询才能保住写法一致性;「静默错列必须消失」的公共下限由 B1 以收敛达成,且消灭「同一谓词、两种写法、一拒一收」的陷阱面。附带:修 label 富化盲区、翻转 infer-cube-where-spelling-parity.test.ts 第 3 组。量级 M。

⚠️ 派发排程:与 #5688 同落 service-analytics(且与刚合的 #5764 同函数),不同轮派发。

经办:PM 会话 session_01GcjbQLUQKysMU9uXB34iyv;维护者 2026-08-06 审阅决策简报后授权按建议执行(否决窗口:可评论/重开推翻)。

---

Generated by Claude Code