Skip to content

summary count/sum 存量 NULL 行的一次性回填 —— #5749 方案 1 落地后的遗留半边(原地升级的库仍漏行) #6063

Description

@baozhoutao

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)。真正的成本在三个取舍:

  1. 开机自动跑 vs 显式 os migrate —— 仓库先例倾向显式且产出证据;
  2. 逐行重算聚合(正确但 O(rows) 次聚合)vs UPDATE … SET col = 0 WHERE col IS NULL(便宜,但仅当「NULL 必然意味着从未重算」对每个驱动都成立时才正确 —— 该推断未经逐驱动验证);
  3. 引擎层驱动无关循环 vs 逐驱动 SQL

取舍 2 若选便宜路线需要先证伪反例;若三取舍需维护者拍板(涉存量数据迁移形状,SKILL 升级门槛点名此类),分诊可直接挂 needs-user-decision

Refs #5749 / PR #6013、os migrate 先例(value-shapes、files-to-references)。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions