 thzxx
|
50b1864145
|
chore(docs): 删除 v0.7.4 审计与 v0.7.5 计划共 4 个 md 文档
删除：
- AUDIT-aria-lsm-v0.7.4.md（50KB）
- AUDIT-query-layer-v0.7.4.md（39KB）
- AUDIT-storage-engines-v0.7.4.md（39KB）
- PLAN-v0.7.5.md（98KB，含附录 G/H/I）
删除前先清除引用面，避免留下断链（共 18 处）：
- 源码注释 7 处（change-notifier / kvstore index / column-value / expression /
sql-compare / where-matcher / validation）：保留设计意图，引用改为"v0.8.0 审计根因 N"
- 测试注释 9 处（opfs.spec / aria-opfs-backend / faulty-backend / storage-harness /
v080-b6 / v080-kvstore / v080-query-layer / v080-sql-three-valued /
v080-unified-validation / parser）：同上
- CHANGELOG 3 处：改为不依赖已删除文档的自洽表述（B-6 交付物见各条；门禁订正三处
按内容重写），并把变异数量同步为 42
- 校验：三个 md 之间无断链；仓库内已无 PLAN-v0.7.5/AUDIT-* 的任何引用
（git 历史仍可追溯，需要时可 `git show <commit>:PLAN-v0.7.5.md` 找回）
验证：93 套件 / 1985 用例全绿；覆盖率 90.59 / 82.61 / 94.14 / 93.50（阈值 90/82/94/93）；
e2e 14/14；lint + 两份 tsc 干净；dist 已重建（注释只影响非压缩产物，min 产物
251,731 B / gzip 63,431 B 不变）。
说明：审查记录的核心内容仍在 CHANGELOG.md（"全量回归审查"与"现场失败修复"两节），
随 PLAN 一起删除的是附录 G/H/I 的详细表格（门禁逐条验收、交付物清单、未修复项表）。
|
2026-09-15 17:17:24 +08:00 |
|
|
thzxx
|
841db2e049
|
fix(A22/A23/A25/A26/A27/A29/A30/A36): 查询层 8 项缺陷根治 + 单一语义收敛
每项都先用可执行探针复现出**错误的实际输出**，再修根因、补永久回归套件
（tests/v080-query-layer.test.ts，8 项 × 4 引擎 + 跨引擎项，共 111 断言）。
A22 GROUP BY 引用 SELECT 别名
修复前：`SELECT g AS grp, COUNT(*) FROM t GROUP BY grp` 抛
`COLUMN_NOT_FOUND Unknown column "g" in SELECT list` —— 错误信息与真正原因
（GROUP BY 用了别名）无关，因为 grp 取到 undefined 使全表并成一组，
投影阶段又发现 g 不在输出行里。
修复：GROUP BY 项先解析回**基列**（别名 → 源表达式）再分组，输出键与
"按基列分组"完全一致。
A23 HAVING 引用未出现在 SELECT 里的聚合
修复前：`SELECT g FROM t GROUP BY g HAVING SUM(n) > 25` → `[]`
（SUM(n) 从未被求值 → HAVING 的键在分组行里不存在 → UNKNOWN）。
修复：需要计算的聚合 = SELECT 列 ∪ HAVING 中的聚合（并集），
并在 HAVING **之后**才把行收缩为 SELECT 输出键（否则又变回 []；
顺序错了会双向出错：先投影 → 空结果，不投影 → 泄漏内部聚合列）。
A25 带表前缀的聚合参数恒 0
修复前：`COUNT(t.n)` → 0、`SUM(t.n)` → null（行键是 n，直接取 row['t.n']
得 undefined 再被"过滤 NULL"剔除，**且不报错**）。
修复：新增唯一列引用解析 resolveColumnValue（前缀剥离 → 精确 → 唯一后缀），
聚合识别统一为 parseAggregateExpression —— 此前"是否聚合"与"如何求值"
用两条不同的正则。取不到列改为抛 COLUMN_NOT_FOUND，不再静默计 0。
A26 UNION 尾部 ORDER BY/LIMIT 归属错误
修复前：`A UNION B ORDER BY id DESC` 只排 B；`... LIMIT 3` 返回 4 行
（parser 把子句挂在右侧 SELECT 上，AST 没有复合查询级字段）。
修复：SelectUnionStatement 增加 orderBy/limit/offset，parser 把子句**上移**
（移动而非复制，否则 LIMIT 应用两次），executor 在合并+去重后统一排序/切片。
A27 DISTINCT 作用在投影前
修复前：`SELECT DISTINCT g AS d FROM t` 返回 4 行 a,a,b,b
（对 {id,g,n} 原始行去重），而 `SELECT DISTINCT g` 返回 2 行。
修复：DISTINCT 移到投影后（作用于输出列）；ORDER BY 的应用时机随之拆成
"引用输出列 → 投影后" / "引用非输出列 → 投影前"，两者互为因果必须一起改。
A29 maxRowsPerQuery 静默截断写入
修复前：maxRowsPerQuery=2 时 `INSERT INTO dst SELECT id FROM src`（4 行源）
只写 2 行并报成功 —— 不是"限制查询规模"而是**静默丢数据**。
修复：行源不截断（executeSelect 增加 purpose='source'），写路径显式报错。
A30 INSERT 值多于目标列静默丢弃
修复前：`INSERT INTO t (id,g) VALUES ('9','z','LOST')` 报成功、'LOST' 消失。
修复：显式列名时解析期拦截（PARSE_ERROR），未给列名时 executor 对照 schema
拦截（VALIDATION_ERROR）——两种情况都需要，因为前者无需 schema。
A36 派生表别名引用
修复前：`SELECT d.id FROM (SELECT id, g FROM t) AS d` 返回 `[]`，
而同义的 `SELECT id FROM (...) AS d` 正确。
修复：抽出 normalizeUnprefixedReferences（WHERE/ORDER BY/GROUP BY/SELECT
四类引用统一剥离别名前缀），非 JOIN 单表路径与派生表路径共用同一规则。
连带根治（修复过程中发现的两个更底层问题）：
1. **同步抛错穿过 async 边界**：`executor.execute()` 里 `return this.executeXxx(stmt)`
的同步前导段若抛错（arity/校验），异常成为**同步抛出** ——
`await expect(db.query(...)).rejects...` 的断言不生效、`.catch()` 永不执行。
现统一包一层 try/catch，保证任何错误都是 rejected promise。
2. **缺列的行形状不一致**：validateRow 此前"值为 undefined 就不落键"，
于是 `INSERT INTO t (id,g) VALUES ('9','z')` 的行里没有 n 键 →
`SELECT id,g,n FROM t` 抛 COLUMN_NOT_FOUND: n，而 `SELECT * FROM t` 正常。
现在缺列且无 default → 显式补 null（SQL 语义），行始终含全部 schema 列；
ALTER ADD 同步在已有行上物化 null，使"内存视图"与"重启后视图"一致。
验证：全量 83 套件 / 1589 测试通过（含 Aria 5 万行索引竞态、KVStore 持久化）；
typecheck(src+tests) 与 lint 零错误。
|
2026-09-15 00:00:08 +08:00 |
|
|
thzxx
|
2a109ef933
|
feat(B-1): 统一行校验 choke point —— 消除三份分叉的校验实现（A12/A17）
背景（PLAN-v0.7.5.md 根因 1）：
修复前有**三份**行校验实现，覆盖面各不相同：
位置 类型 required PK非空 maxLength min/max 未知列
engine/memory.ts（disk/hybrid 共用） ✓ ✓ ✓ ✗ ✗ 静默丢弃
engine/aria/index.ts → checkFieldType ✓ ✓ ✓ ✓ ✓ 静默丢弃
table/schema.ts ✓ ✓ ✓ ✓ ✓ 静默丢弃
后果一（A12）：同一份 schema、同一条 INSERT 是否报约束错误取决于引擎选择 ——
`CREATE TABLE t (name STRING(3))` + 插入 'abcdef' 在 Aria 抛错，在
memory/disk/hybrid 静默写入超长值。
后果二（A17）：四个引擎对未知列一律静默丢弃。`INSERT INTO t (id, nope) VALUES
('1',2)` 报成功，随后 `SELECT nope` 报 COLUMN_NOT_FOUND —— 同一列名在写路径与
读路径得到**相反结论**。TABLE API 直通路径尤其明显（executor 按 schema 列序
构造行，nope 那个位置根本没有值，所以连"校验 stmt.columns"都拦不住）。
根治方式：
1. 新增 src/table/validation.ts —— 唯一校验定义 `compileValidator(schema)`，
约束覆盖面取三者并集，并把**规范化**（default 填充、undefined 跳过、
__proto__ 防污染）与校验放在同一处。
三种载荷形态刻意分成三个显式入口，不合成带 options 的函数：
- validateRow(row, knownColumns?) INSERT 语义（default 生效、缺列合法）
- validatePartial(row) UPDATE 语义（只校验出现的列）
- assertNoUnknownColumns 独立可复用的列名存在性检查
混成一个函数会让"required 是否生效"取决于调用方参数，重新引入跨路径差异。
2. MemoryEngine / AriaEngine 的私有 validateRow 改为委托；schema.ts 的公开
validateRow 同样委托（API 不变，实现只剩一份）。
3. 四个引擎新增 validatePayload(table, rows, mode)（IStorageEngine 契约），
Executor 在**任何副作用之前**调用：多行批量整体判定，错误消息一次列出全部
未知列与已知列清单。
4. executeInsert 显式校验 stmt.columns 全部存在（A17）。
5. UPDATE 的外键级联写入（applyUpdateCascade）从"直接赋值"改为过
validatePartial —— 此前 CASCADE 把新主键写进引用列时绕过 maxLength/min/max，
与 A12 属同一类"校验只在部分写入路径生效"。
连带修正（测试夹具本身不忠实，B-1 使其暴露）：
- tests/engine/aria-cache.test.ts 的 makeRows 无条件返回 {id,name,age}，
部分用例的表只有 {id,name} —— 多余列被静默丢弃所以"通过"。新增 rowsFor()
按 schema 裁剪，让夹具忠实反映表结构（而不是放宽校验）。
- tests/v073-fixes.test.ts "schema 外列不持久化" 改为断言写路径即拒绝，
并保留"合法行落盘后不含额外列"的检查。
验证：
- 新增 tests/v080-unified-validation.test.ts：8 项 × 4 引擎 + 9 项校验器
单元契约，共 41 断言；
- 全量 84 套件 / 1499 测试通过；typecheck(src+tests) 与 lint 零错误。
|
2026-09-14 23:38:58 +08:00 |
|