docs(debt): 补记之十一 —— PK 断言要"走迁移路径"才有判别力；★ 并给出可执行形状 + 线上现状实测

① ✅ pi §四 确认，并量化"为什么"（/tmp/pktest 实测）:
   全新库: PK 来自 DDL 本身 ⇒ 断言**恒绿**、零判别力
   旧  库: 重跑同一份 DDL（CREATE TABLE IF NOT EXISTS 命中已存在表 ⇒ 原样跳过）
           ⇒ PK 仍是 `PRIMARY KEY (agent_name, platform_id)`
   ⇒ 两种情形**同一份断言**，差别只在"库怎么来的"
   ⇒ ★ 判据必须**自己造一个旧库**（老 DDL 建表 → 灌行 → 跑迁移 → 断言），
     否则它测的是"DDL 文本对不对"，而那件事**永远成立**

② ★★ 线上现状（2026-09-27 04:0x 实测）—— 正是"改 DDL 对生产静默无效"的现场:
   PK 列 = `agent_name , platform_id`（**仍是旧的**）
   索引  = `idx_platform_sessions_ws`（在，今天还没被任何重建吞掉）
   行数  = 278
   ⇒ 文件里 PK 写什么，库里都不是那个；而全部测试绿

③ ★ 判据/自检该用哪种读法（两个都实测）:
   ✅ `pragma_table_info` 的 **pk>0 列按 pk 序号排序**后逐项比对
      旧库 ⇒ agent_name, platform_id;  全新库 ⇒ agent_name, workspace, platform_id
   ✗ `LIKE '%(agent_name, workspace, platform_id)%'` 匹配 PK 文本:
      在**旧库（PK 明知是错的）上不命中** ⇒ 判据会"**绿着一个错的库**"
   ⚠️ pragma 的 pk 顺序**可能与声明书写顺序不同**
      （PRIMARY KEY (agent_name, platform_id, workspace) 在 pragma 里就是这个顺序）
      ⇒ **必须按 pk 序号排序后逐项比**，只比集合会漏掉次序差异

④ ★ 由此给出"迁移后自检"的最小形状（今天可写、现在**红**、修好即绿）:
   在 `Migrate` 末尾对 agent_platform_sessions 断言三样:
     ① pk 列（按序号）== (agent_name, workspace, platform_id)
     ② idx_platform_sessions_ws 存在
     ③ 无 agent_platform_sessions_new 残留
   ★ 与 (a)(b)(c) 的区别: 那些是**测试**断言（要自己造旧库才有判别力），
     这一条是**启动路径上的自检** ⇒ **生产也会响** —— 否则缺陷在生产上永远不暴露

校验: go test ./internal/repo/ -run Debt -count=1 ⇒ ok; 临时目录已清

This commit is contained in:

JianFeeeee

2026-09-27 04:05:33 +08:00

parent ac09c496e2

commit 8b2c9a8fb8

1 changed files with 1 additions and 1 deletions

2

docs/DEBTS.json

View File

File diff suppressed because one or more lines are too long

docs(debt): 补记之十一 —— PK 断言要"走迁移路径"才有判别力；★ 并给出可执行形状 + 线上现状实测

2 docs/DEBTS.json View File

2

docs/DEBTS.json

View File