observation: inferCube 仍把数组 where 当「不是筛选」跳过 —— #5334 之后这个 !Array.isArray 守卫已经过时

实现 #5334 时路过,记录一条观察类发现(今天没有用户能撞到的行为差异),unassigned、不进队列。

位置

packages/services/service-analytics/src/analytics-service.ts,inferCube(为没有注册 Cube 的自由查询即席合成一个 Cube):

if (query.where && typeof query.where === 'object' && !Array.isArray(query.where)) {
  // Canonical FilterCondition: top-level keys ... are field names.
  for (const key of Object.keys(query.where as Record< string, unknown >)) { ... }
}

!Array.isArray(query.where) 这个守卫写于「数组 where 不是筛选」的年代。#5334 之后数组 where 是真筛选(isFilterAST → parseFilterAST 下沉),于是:数组写法的筛选所涉字段不会被种进即席 Cube 的 dimensions,对象写法的会。同一份筛选,两种写法,合成出两个不同的 Cube。

为什么今天没有可观察后果(所以是 observation 类)

NativeSQLStrategy.resolveFieldSql 在 cube 里找不到该 member 时回落到裸列名,所以 WHERE 子句照样编译、照样绑值、取到的行一致(#5334 的等价性用例覆盖的正是这条)。差异只落在即席 Cube 的 dimensions 清单上,而该清单在这条路上仅用于字段元数据与列歧义限定 —— 即席 Cube 是单表、无 join,没有歧义可限定。

会变成真缺陷的条件:即席路径将来长出 join,或者字段元数据/歧义限定开始依赖这份 dimensions。

建议

守卫改成「先下沉再取键」(复用 #5334 落在 filter-normalizer.ts 的那次下沉,或直接 parseFilterAST),而不是把数组当非筛选跳过。规模很小,但不该顺手塞进 #5334 的 PR —— 那单的裁定范围就是 normalizeAnalyticsFilterTree 一处。

搜过 open issues(inferCube / analytics where dimensions),无同题单。

关联:#5334、#5158(拍板 C)、#5329。

发现分诊轮判级:晋级 —— 摘 finding 换 pm:queue,补 domain:services。理由:过时前提检查通过(origin/main analytics-service.ts:1200 的 !Array.isArray(query.where) 守卫仍在,#5334 的下沉工具已落地可复用),修法小而明确(守卫改「先下沉再取键」),且它是「即席路径长出 join 前」拆雷的窗口期修复——留到有可观察后果时再修,成本只会更高。

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

Generated by Claude Code

认领(services 车道 PM 派发,session_01BWS4heBoAitLmzCLhcYdbK)

分支:claude/issue-5353-infercube-array-where
worktree:../objectstack-issue-5353(dev 子代理按 worktree-first 自建)
文件面:packages/services/service-analytics/src/analytics-service.ts(inferCubeFromQuery 的 !Array.isArray 守卫改「先下沉再取键」)、同包测试、.changeset/*.md。
串行约束已清:同文件前序 analytics: where 里点名不存在的字段仍然一路到驱动 —— #4437(measure)/ #5520(dimension)之后,filter 面是同一个缺陷剩下的第三个 param #5669(PR fix(service-analytics): where 源字段闸门 —— 点名不存在字段的筛选答 400 INVALID_FIELD 而非驱动 500 (#5669) #5740)刚 merged。派发要点(来自 analytics: where 里点名不存在的字段仍然一路到驱动 —— #4437(measure)/ #5520(dimension)之后,filter 面是同一个缺陷剩下的第三个 param #5669 报告):下沉直接复用 normalizeAnalyticsFilterTree(该 PR 已在本文件 import 并验证),无需自接 parseFilterAST;落地后即席 cube 的 dimensions 会多出数组 where 的键,resolveMemberSource 对这些 member 从「未声明裸列」走到「已声明 dimension」分支 —— 两分支同源同判定,fix(service-analytics): where 源字段闸门 —— 点名不存在字段的筛选答 400 INVALID_FIELD 而非驱动 500 (#5669) #5740 的闸门 doc 已写明,回归以此为准。analytics 自动推断路径:inferCubeFromQuery 的 stripPrefix 把关系穿越 owner.region 铸成基表列 region —— 基表恰好有同名列时静默筛/分组错列(两个策略、两个请求键均如此) #5739(stripPrefix 遮蔽关系穿越)是同函数邻居缺陷、产品裁定级,本单不碰。

Generated by Claude Code

分诊备忘(同文件串行提示,未派发、不构成认领):

本单与新立的 #5739 同落 packages/services/service-analytics/src/analytics-service.ts 的 inferCubeFromQuery(origin/main 889ae47:stripPrefix 在 1152/1559,数组 where 守卫与其相邻)。按 SKILL step 3 的同文件串行纪律,两单不得同轮派发。

更要紧的是成本耦合:#5739 请求的裁决是「stripPrefix 要不要区分 <cube>. 限定符与关系路径」,一旦裁「区分」,该函数的铸造判定本就要重写 —— 届时把本单的 !Array.isArray(query.where) 过时守卫在同一次改动里一并下沉,成本远低于分两次改同一个函数。#5739 正文亦如此建议。

⚠️ 因此在 #5739 拿到裁决前认领本单的,请在认领评论里申明是否连带收 #5739 的半边;若只做本单,请预期该函数近期会被再次改写。

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

Generated by Claude Code

fix(service-analytics): gate `where` source fields — a filter over a …

fix(service-analytics): lower the `where` before seeding an ad-hoc cu…

fix(service-analytics): an inferred cube lives only in its request — …

Navigation Menu

Repository navigation

observation: `inferCube` 仍把数组 `where` 当「不是筛选」跳过 —— #5334 之后这个 `!Array.isArray` 守卫已经过时 #5353

位置

为什么今天没有可观察后果(所以是 observation 类)

建议

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

observation: inferCube 仍把数组 where 当「不是筛选」跳过 —— #5334 之后这个 !Array.isArray 守卫已经过时 #5353

Description

位置

为什么今天没有可观察后果(所以是 observation 类)

建议

Activity

os-zhuang commented on Aug 5, 2026

os-zhuang commented on Aug 6, 2026

claude commented on Aug 6, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

observation: `inferCube` 仍把数组 `where` 当「不是筛选」跳过 —— #5334 之后这个 `!Array.isArray` 守卫已经过时 #5353