MetonaTeam/MetonaSqlark
2
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: PLAN 附录 F 补记 PC-2 与 A37（测试规模 1697/86 + e2e 14）

Browse Source
This commit is contained in:
thzxx
2026-09-15 01:22:16 +08:00
parent 567d150257
commit 0c5c0b1d20
1 changed files with 17 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PLAN-v0.7.5.md
+17 -9
View File
@@ -717,6 +717,8 @@ connection-manager/integrations/migration）两份完整报告，以及测试质
| `b20d47b` | **B-3 单管线** | QueryBuilder 只产出 AST、执行一律经 Executor（删除无 JOIN 时直通 `engine.find` 的快路）；钩子改为由 `Table` 注入、顺序与传参不变；删除引擎层 4 处"未解析标记 → NOT_SUPPORTED"的过时防御 | | `b20d47b` | **B-3 单管线** | QueryBuilder 只产出 AST、执行一律经 Executor（删除无 JOIN 时直通 `engine.find` 的快路）；钩子改为由 `Table` 注入、顺序与传参不变；删除引擎层 4 处"未解析标记 → NOT_SUPPORTED"的过时防御 |
| `edd9f1d` | **B-6 ①②（两处 P0）** | ① `open()` 遇损坏日志尾部不再**清空整库**（新增 `truncateLogTo(keepBytes)`，与 `repair()` 同口径）；② 自动 checkpoint 失败不再让**已确认写入**报错（WAL 已持久化），改为记 `lastBackgroundError` 并由下一次显式 `checkpoint()` 报告 | | `edd9f1d` | **B-6 ①②（两处 P0）** | ① `open()` 遇损坏日志尾部不再**清空整库**（新增 `truncateLogTo(keepBytes)`，与 `repair()` 同口径）；② 自动 checkpoint 失败不再让**已确认写入**报错（WAL 已持久化），改为记 `lastBackgroundError` 并由下一次显式 `checkpoint()` 报告 |
| `68e4731` | **B-6 ③ + 测试介质** | ③ meta 增加 `owner`，陈旧实例 `checkpoint()` 抛 `STALE_INSTANCE` 拒绝覆盖新实例的写入（实测修复前会**静默**抹掉）；同时修复 `SharedMemoryBackend` 的跨实例可见性缺陷（私有拼接缓存使介质退化为"每实例一份快照"，此前所有多实例用例都跑在错误介质上） | | `68e4731` | **B-6 ③ + 测试介质** | ③ meta 增加 `owner`，陈旧实例 `checkpoint()` 抛 `STALE_INSTANCE` 拒绝覆盖新实例的写入（实测修复前会**静默**抹掉）；同时修复 `SharedMemoryBackend` 的跨实例可见性缺陷（私有拼接缓存使介质退化为"每实例一份快照"，此前所有多实例用例都跑在错误介质上） |
| `6a0cfeb` | **PC-2 真崩溃注入** | e2e 的 `crashPage()` 原本只是 `win.__ms = null; page.close()` —— **优雅关闭**，所有"崩溃恢复"用例测的其实是"正常关闭后重开"（CI 注释却声称覆盖 CDP `Page.crash`）。现改用 CDP `Page.crash` 终止渲染进程，并新增两个真实窗口：`createWritable().write()` 中途、`close()` 原子替换前（copy-on-write 的核心不变量）。实测要点：崩溃后 `page.isClosed()` 仍为 false；OPFS 数据在同 context 内跨崩溃保留 |
| `567d150` | **A37 列引用** | 未限定列可作比较操作数（`WHERE x = y` / `ON k = k` 此前 PARSE_ERROR，列对列比较被迫写限定形态）；新增 WHERE / JOIN ON 的列存在性校验 —— `$col` 引用不存在的列此前**静默返回空集**（`WHERE id = oops` → `[]`），现报 `COLUMN_NOT_FOUND`；顺带解除 `schema ↔ validation` 循环依赖 |
### 三值逻辑根治（A15 / PB-2，提交 `4ab04df`） ### 三值逻辑根治（A15 / PB-2，提交 `4ab04df`）
@@ -795,18 +797,24 @@ connection-manager/integrations/migration）两份完整报告，以及测试质
| ~~P0~~ | ~~**B-3 单管线**（builder 只产出 AST）~~ | ✅ `b20d47b` | | ~~P0~~ | ~~**B-3 单管线**（builder 只产出 AST）~~ | ✅ `b20d47b` |
| ~~P0~~ | ~~**B-6 KVStore 三处止血**~~ | ✅ `edd9f1d` + `68e4731` | | ~~P0~~ | ~~**B-6 KVStore 三处止血**~~ | ✅ `edd9f1d` + `68e4731` |
| P1 | A13/A14 自引用外键失效、ON UPDATE CASCADE 只一层 | 待做 | | P1 | A13/A14 自引用外键失效、ON UPDATE CASCADE 只一层 | 待做 |
| P1 | A35/A37 JOIN NULL 键（已修）、未限定列名（PARSE_ERROR 显式拒绝） | 部分 ✅ | | ~~P1~~ | ~~A35 JOIN NULL 键~~ | ✅ `841db2e`（JOIN 的 NULL 键不成立，且与右表有无索引无关） |
| ~~P1~~ | ~~A37 未限定列名 / WHERE 列存在性~~ | ✅ `567d150` |
| P1 | A38/A39 `compression` 被 pageStorage 遮蔽、`compressLZ4` O(n²) | 待做 | | P1 | A38/A39 `compression` 被 pageStorage 遮蔽、`compressLZ4` O(n²) | 待做 |
| P1 | A40/A41 Aria `close()` 活跃事务守卫、`dropTable` DDL 原子性 | 待做 | | P1 | A40/A41 Aria `close()` 活跃事务守卫、`dropTable` DDL 原子性 | 待做 |
| P0 | **B-6 存储单一提交点（manifest）** | 部分（KVStore 已完成；Aria 见 A40/A41） | | P0 | **B-6 存储单一提交点（manifest）** | 部分（KVStore 三处止血已完成；Aria 见 A40/A41） |
| P1 | **B-4 统一表达式求值器**（CASE 正则切分、聚合表达式、列引用） | 待做（A25 已先修其载体） | | P1 | **B-4 统一表达式求值器**（CASE 正则切分、聚合表达式、列引用） | 部分（聚合与列引用已统一，见文末说明） |
| P1 | **B-5 结构化 AST 表达式节点 + 输出列序号** | 待做 | | P1 | **B-5 结构化 AST 表达式节点 + 输出列序号** | 待做 |
| — | PC-2 e2e 真崩溃注入（CDP `Page.crash`） | 待做 | | ~~—~~ | ~~PC-2 e2e 真崩溃注入（CDP `Page.crash`）~~ | ✅ `6a0cfeb`（14 项 e2e，含两个 OPFS 写入窗口） |
| — | PC-4/PC-5 契约测试 + 属性测试 | 部分（跨引擎参数化已用于 A1/A2/A15/B-1/B-3） | | — | PC-4/PC-5 契约测试 + 属性测试 | 部分（跨引擎参数化已用于 A1/A2/A15/B-1/B-3） |
| — | PG 文档与站点全量同步 | 待做 | | — | PG 文档与站点全量同步 | 待做 |
**下一步建议**：PC-2 真崩溃注入（e2e 通过 CDP `Page.crash`，覆盖"写入未 await **下一步建议**：A13/A14（外键传递闭包：自引用外键与多层 ON UPDATE CASCADE）
即崩溃 / checkpoint 中途崩溃 / WAL 半写"三个窗口）—— 这是**验证**已完成的 → A38/A39（`compression` 被 pageStorage 遮蔽、`compressLZ4` O(n²)）→ A40/A41
崩溃语义声称的关键一步，目前所有崩溃结论都来自单元级故障注入； （Aria `close()` 活跃事务守卫、`dropTable` DDL 原子性）→ B-4 统一表达式求值
随后 B-4（统一表达式求值，消除 CASE 正则切分整类）→ A13/A14（外键传递闭包） （CASE 正则切分整类）→ B-5 结构化 AST → PG 文档与站点同步。
→ A38~A41（存储层剩余）→ B-5 → PG。
**关于 B-4/B-5 的现状**：二者的"载体"已在其他修复中先行落地 ——
`parseAggregateExpression` / `resolveColumnValue`（B-4 的聚合与列引用部分）、
`sqlCompare`/`encodeValueKey`（统一值语义）、`normalizeUnprefixedReferences`
（统一引用归一化）。剩余部分（CASE 的正则切分、输出列序号）影响面小于
A13/A14 与 A38~A41，故排序在后。