analytics 的 getObjectDatasource 报告的是「声明值」而非「有效 datasource」:#5033 的诊断会点错库,#5115 的编译期闸门看不见隐式路由的对象

[os-zhuang]

现象

AnalyticsServiceConfig.getObjectDatasource 在 plugin.ts 里是这样接出来的:

getObjectDatasource: (objectName: string) = dataEngine()?.getObject?.(objectName)?.datasource,

它读的是对象声明的 object.datasource。但真正决定这个对象的行落在哪个库的是 ObjectQL.getDriver 的五步解析顺序:

1. 显式的 object.datasource(且不等于 'default')—— 直接短路;
2. datasourceMapping 规则;
3. ADR-0057 §3.6 生命周期分流:lifecycle.class 为 audit / telemetry / event 的对象,在 telemetry datasource 已注册时路由过去;
4. 所属 package manifest 的 defaultDatasource;
5. 全局默认 driver。

也就是说,探针只覆盖第 1 步。ObjectSchema.datasource 带 .default('default'),所以一个由 2/3/4 步路由到别处的对象,探针照样回答 'default' —— 而 'default' 在 getDriver 里恰恰表示「没有显式绑定,继续往下查」,不是「主库」。

今天就能碰到的后果

(a) #5033 的查询期诊断会点错库。 analytics-service.ts 的 missing-source 分诊用这个探针拼错误文案:

table "X" is not on datasource "Y", which is where its base object "B" lives

sys_audit_log —— 也就是 #5033 那条 issue 的主角 —— 是靠 lifecycle.class: 'audit' 被分流到 telemetry 的,不是靠显式字段。于是这句话会说它在 datasource "default"(或「the default datasource」),把读的人指向一个它根本不在的库。文案的意义就是「点名真实原因」,这里点名的是错的。

(b) #5115 的编译期闸门覆盖不到隐式路由的对象。 #5115(PR #5287)在编译期拒绝跨 datasource 的 join,判据只能收窄到「双方都显式声明了 datasource 且不同」—— 因为把 'default' 当成主库会误拒那些被 mapping 规则落到同一个库的 dataset(误拒 = 升级后看板变白)。结果是:催生 #5115 的那个真实场景(audit 对象靠生命周期分流跨库)对该闸门是不可见的。

建议方向(未实现,留给分诊)

在引擎侧补一个权威的「对象的有效 datasource 名字」访问器 —— 相当于把 getDriver 的解析顺序抽出来只算名字、不取 driver,然后让 plugin.ts 的探针改接它。resolveMappedDatasource(#4462)已经为「不要在别处重写一遍路由规则」开了先例,datasource-connection-service 里也明确写着第二份实现必然漂移 —— 同样的理由适用于这里:analytics 侧不应该自己重算生命周期分流和 package 默认值。

补上之后:

• service-analytics 的 executeRawSql 自动桥接丢弃 objectName —— dataset 原始 SQL 永远打在默认 datasource 上,凡被路由到非默认 datasource 的对象一律读成 0 #5033 的诊断文案自动点对库;
• dataset 跨 datasource JOIN 应在编译/发布期就被拒绝,而不是留到查询期才响亮失败(#5033 的后续) #5115 的判据可以在不引入误拒的前提下扩到隐式路由的对象(因为那时 'default' 之外的答案才是真的「有效值」);
• 发布闸门那一单(lint 侧,见 dataset 跨 datasource JOIN 应在编译/发布期就被拒绝,而不是留到查询期才响亮失败(#5033 的后续) #5115 的调研结论)在运行期侧也有了对照实现。

注意

改动落点大概率是 packages/objectql/src/engine.ts,该文件目前有在飞单(#5272),排期时留意冲突面。

出处:实现 #5115 时观察到(PR #5287),该 PR 已把这条限制写进代码注释、changeset 与 PR 正文,行为上以「证明不了就不拒绝」的方式规避,不依赖本单。

[os-zhuang]

分诊结论

分类:pm:queue(具体缺陷,落点明确)
领域:domain:engine(跨域,详见下)

Stale-premise 核对(对 origin/main @ 最新 fetch 复核,非基于本 issue 引用的旧 commit)

• packages/services/service-analytics/src/plugin.ts:566 的 getObjectDatasource 探针原样成立:

  getObjectDatasource: (objectName: string) => dataEngine()?.getObject?.(objectName)?.datasource,

  只读声明值,注释里也明确写着「Undefined ⇒ the object rides the default datasource (or the engine cannot answer)」——即作者已知这是声明值口径,不是有效路由口径。
• packages/objectql/src/engine.ts:3125 的私有 getDriver() 五步解析顺序(显式 datasource → datasourceMapping → ADR-0057 §3.6 生命周期分流 → package defaultDatasource → 全局默认)与 issue 描述逐条一致,均在 origin/main 上原样可见。
• service-analytics 的 executeRawSql 自动桥接丢弃 objectName —— dataset 原始 SQL 永远打在默认 datasource 上,凡被路由到非默认 datasource 的对象一律读成 0 #5033(PR fix(service-analytics): executeRawSql 桥接透传 objectName —— dataset 原始 SQL 打回对象自己的 datasource (#5033) #5119 合并)与 dataset 跨 datasource JOIN 应在编译/发布期就被拒绝,而不是留到查询期才响亮失败(#5033 的后续) #5115(PR fix(service-analytics): 编译期拒绝 dataset 的跨 datasource JOIN (#5115) #5287 合并)均已关闭,但都没有触碰这个探针本身——fix(service-analytics): executeRawSql 桥接透传 objectName —— dataset 原始 SQL 打回对象自己的 datasource (#5033) #5119 只是新增了它(用于诊断文案),fix(service-analytics): 编译期拒绝 dataset 的跨 datasource JOIN (#5115) #5287 只是消费它并在代码注释里明确写出「'default' 不是路由答案」从而把编译期判据收窄到「双方都显式声明」。两个 PR 的收尾都点名把这条账记在本 issue,均未依赖本 issue 解决。premise 完全未被上述两个已合并 PR 改变,仍然成立。
• 备注:issue 正文提到的冲突面 单记录 delete 从不绑定 hookContext.previous —— 契约声明「for update/delete」,引擎只在 update 分支赋值;#5038 之后批量 delete 反而比单记录 delete 更完整 #5272(engine.ts 在飞单)已于合并当天关闭(state_reason: completed),该冲突风险已消解,不影响排期。

去重核对

• 全仓(objectstack/objectui/cloud)搜索 getObjectDatasource 及相关关键词,只命中本 issue 与已关闭的 service-analytics 的 executeRawSql 自动桥接丢弃 objectName —— dataset 原始 SQL 永远打在默认 datasource 上,凡被路由到非默认 datasource 的对象一律读成 0 #5033/dataset 跨 datasource JOIN 应在编译/发布期就被拒绝,而不是留到查询期才响亮失败(#5033 的后续) #5115/PR fix(service-analytics): executeRawSql 桥接透传 objectName —— dataset 原始 SQL 打回对象自己的 datasource (#5033) #5119/PR fix(service-analytics): 编译期拒绝 dataset 的跨 datasource JOIN (#5115) #5287,objectui、cloud 均无命中——无 shadow 单或在飞 PR。
• 与同批分诊的 分析查询的 {field: {$eq: null}} / {$ne: null} 编译成 col = '' / col != '',与同文件里 {field: null} 的 IS NULL 自相矛盾 #5332({$eq: null} 编译成 = '')、/analytics/sql 回显的 SQL 丢掉 $startsWith / $endsWith 谓词:回显比实际执行的查询更宽,无法复现结果 #5333($startsWith/$endsWith 回显丢失)核对后确认不是同一缺陷:那两单是 filter-normalizer.ts / objectql-strategy.ts 里比较算子/比较值编译错误(过滤条件语义),而本单是 plugin.ts/engine.ts 里对象到 datasource 的路由归属判定错误,文件、根因、影响面均不重叠,仅同属 analytics 缺陷调查系列,不构成重复。

领域判定与跨域说明

按建议方向,核心修复是在引擎侧新增一个只算「有效 datasource 名字」、不取 driver 的权威访问器(把 getDriver() 五步解析顺序抽出来,类比 engine.ts:3250 已有的 resolveMappedDatasource 公开包装先例),这个新增点落在 packages/objectql/src/engine.ts → domain:engine。随后 packages/services/service-analytics/src/plugin.ts 的探针需要改接这个新访问器 → 涉及 domain:services。按 contract-first 排序(producer/engine 先行),主落点判 domain:engine;该单确实跨两个域,后续实现可能需要拆成「engine 新增访问器」+「service-analytics 切换探针」两步或两个 PR,请分派时留意。

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

---

Generated by Claude Code