Repository navigation
summary count/sum 存量 NULL 行的一次性回填 —— #5749 方案 1 落地后的遗留半边(原地升级的库仍漏行) #6063
Description
Part of #5749(其 PR #6013 只治新数据;分诊裁定存量回填单独立单)。未指派,标签交分诊;实测定价来自 #5749 的 dev 报告,原文要点如下。
事实
PR #6013 让新建父行的 count/sum 汇总自 insert 起为 0;已存成 NULL 的存量父行仍为 NULL,直到某次子记录写入触发重算。即 --fresh/重新 seed 的部署正确,原地升级的存量库仍会在 filter = 0 上漏行(showcase 的 Legacy Sunset 即例)。
形状与三个取舍(dev 实测定价,非猜测)
一次性数据迁移,沿用 os migrate 家族先例(value-shapes / files-to-references):遍历注册对象中拥有 count/sum descriptor 的汇总列,补齐 IS NULL 行。代码量约一个 dev session(迁移模块 + 注册项 + 测试 + changeset)。真正的成本在三个取舍:
- 开机自动跑 vs 显式
os migrate—— 仓库先例倾向显式且产出证据; - 逐行重算聚合(正确但 O(rows) 次聚合)vs
UPDATE … SET col = 0 WHERE col IS NULL(便宜,但仅当「NULL 必然意味着从未重算」对每个驱动都成立时才正确 —— 该推断未经逐驱动验证); - 引擎层驱动无关循环 vs 逐驱动 SQL。
取舍 2 若选便宜路线需要先证伪反例;若三取舍需维护者拍板(涉存量数据迁移形状,SKILL 升级门槛点名此类),分诊可直接挂 needs-user-decision。
Refs #5749 / PR #6013、os migrate 先例(value-shapes、files-to-references)。
Activity
claude commentedon Aug 6, 2026
分诊(主分诊轮):
needs-user-decision+domain:engine-core,⛔ 不入pm:queue。分类理由(为什么归决策箱而不是直接入队)
正文形状是存量数据迁移,SKILL step 0 的 maintainer-confirm 一类点名此形(anything touching stored-data migration shape)。更硬的依据是本单的既有裁决,两条都在链上:
needs-user-decision,不要在 PR 里顺手定」;⇒ 本单就是那条裁决的落地入口,三取舍(自动跑 vs 显式
os migrate、逐行重算 vs 条件UPDATE、引擎层驱动无关循环 vs 逐驱动 SQL)交维护者拍板。取舍 2 的风险方向具体:col IS NULL ⇒ 从未重算这条推断按正文自陈未经逐驱动验证,选便宜路线必须先证伪反例,否则回填本身会写错数据 —— 这是「便宜/贵」之外的正确性维度,不宜由 dev 在实施中自决。域/落点锚定(不按标题词汇猜)
domain:engine-core。落点实读:方案 1 的交付 PR #6013 只改两个文件 ——packages/objectql/src/engine.ts(+138)与packages/objectql/src/summary-rollup.test.ts;recomputeSummaries()/ 汇总 descriptor 全部在packages/objectql,按域表即engine-core。若取舍 1 选「显式os migrate」,packages/cli/src/commands/migrate/只加一层薄命令注册(仓库先例files-to-references:命令壳在packages/cli、真迁移在归属包packages/services/service-storage),⇒ 主要落地站点仍是 objectql,不改域判。过时前提检查(给出一条修正)
正文题面写「#5749 方案 1 落地后的遗留半边」——方案 1 尚未落地:PR #6013 于本评论时点仍 open(created 14:54Z,
mergeable_state: clean,非 draft),未合入origin/main。两点推论:packages/objectql/src/engine.ts,且回填的正确口径(count/sum 落 0、min/max/avg 保持 null)由 fix(objectql): 新建父行时把 count/sum 型 summary 汇总初始化为 0 (#5749) #6013 建立 —— 抢跑等于对着一份还没定的口径写迁移。needs-user-decision(状态机上本就不可派发),故未打pm:blocked、未改正文加Blocked-by:行 —— 避免一个「标签说待决、正文说被阻塞」的双状态;这条串行约束由本评论承载,裁决后入队的座位请照此排序(届时若 fix(objectql): 新建父行时把 count/sum 型 summary 汇总初始化为 0 (#5749) #6013 仍未合,再补pm:blocked+Blocked-by:成对落地)。查重(三仓 open issue + open PR 各一遍)
无影子单。命中项逐条判过:#5749(父单,
pm:dispatched,治新数据)、PR #6013(其交付)、#6014(pm:queue+domain:engine-core,同属 summary 语义面但落packages/objectql/src/validation/rule-validator.ts,与本单的engine.ts文件不相交,同车道不同批即可)。objectui / cloud 侧零命中。归挂(为什么不做 #5749 的 sub-issue)
正文的
Part of #5749保留为来源行,但不挂为 sub-issue:已排队/在飞父单的 sub-issue 会自动成为派发候选(step 1),把一条尚未裁决的取舍挂进去等于让未分诊的东西静默入池(SKILL 发现分诊轮的「归挂限定」)。且 #5749 自己的裁决已明说这半边独立立单,不属其完成范围。本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
baozhoutao commentedon Aug 7, 2026
【裁决落地】维护者 2026-08-07(rc.4 发布日)经执行席会话通道批复「按建议执行」,本单三取舍裁定如下:
os migrate,不开机自动跑 —— 仓先例(value-shapes / files-to-references)倾向显式且产出证据;命令壳照先例落packages/cli,真迁移落归属包(objectql);recomputeSummaries机制,count/sum 落 0、min/max/avg 保持 null)—— 便宜路线UPDATE … SET col = 0 WHERE col IS NULL默认禁用,仅当实施中拿出逐驱动证据证伪「存在 NULL 但已重算过」的反例后方可替换(分诊点名的正确性维度,不得由 dev 静默自决);可证伪前提:#6013 已于 2026-08-06 MERGED(串行前提解除);若实施中发现 #6013 的口径与本裁定描述不符,停下报告,禁静默改道。
rc.4 口径:本单今日派发;落地赶上切版即随 rc.4,否则 rc.5 —— 在此之前「原地升级库存量 NULL 行在
= 0筛选上漏行」按 known-issue 进 release notes(由发布流程从本单取材,⛔ 本单 PR 不碰content/docs/releases/)。流转:摘
needs-user-decision→ 直接pm:dispatched(本席即刻派发)。执行席 PM
session_019Q7oc7ASjh8yxyS3Yz78We。Generated by Claude Code
baozhoutao commentedon Aug 7, 2026
认领(执行席 PM,engine-core 车道,rc.4 发布优先序)
session_019Q7oc7ASjh8yxyS3Yz78Weclaude/issue-6063-summary-null-backfill../objectstack-issue-6063(worktree-first)packages/cli/src/commands/migrate/薄命令壳(files-to-references 先例);changeset。⛔ 不触engine.ts现有区域(ObjectQLseedAutonumber把读故障答成return 0—— 对已有 N 行的表重新从 1 发号,自增号与既有行相撞且零日志(#4825 同族,活体) #5979 在飞)、不触rule-validator.ts(rule-validator 里 RUNTIME_OWNED_FIELD_TYPES 的排除理由对 summary 是错的:summary 是「存储列」不是「读时计算」 #6014 在飞)按上一条裁决落地评论的三取舍执行。
Generated by Claude Code
fix(cli): type the objectql lookup in summary-nulls instead of erasin…