25 Commits

Include renames

Author	SHA1	Message	Date
thzxx	c5694b1d23	feat(B-6): 存储层单一提交点（__aria_manifest）+ LSM 结构根治 ... 按 PLAN-v0.7.5.md §B-6 的**完整规格**实施（此前只落地了"降级选项"里的五处止血）： B-6 要求的是 `__aria_manifest` 单一提交点 + LSM 单项改造。完整记录见方案附录 H。 一、单一提交点 - 新增 `src/engine/aria/store/manifest.ts`：`__aria_manifest_<generation>` （magic + formatVersion + generation + 头部 CRC + 载荷 CRC；先写后验；保留两代）。 载荷 = 页面水位 + 各命名空间 SSTable 元数据 + 表结构 + WAL 起始位置 + 待落盘冻结表意图。 - 顺序固定：**数据落盘 → manifest 提交 → 才允许截断 WAL / 删除旧文件 / 删除旧 SSTable**。 - 恢复只认最后一份 CRC 通过的世代；全部世代无效 → `ARIA_MANIFEST_CORRUPT` （修复前：裸 JSON meta 解析失败 → `[]` → 静默空库，随后 repair 还会删光活页）。 - 旧格式（__aria_lsm_meta/__aria_schemas/__aria_meta）首次打开自动迁移，旧键保留； 迁移遇到损坏 → `ARIA_LEGACY_META_CORRUPT`。 - 陈旧实例保护（STALE_INSTANCE）：认领时一次跨过 MANIFEST_TAKEOVER_STRIDE 个世代， 杜绝"旧实例在途提交落在同一世代号上"（实测第二个实例 open 直接失败）。 二、LSM - 44 冻结表成为一等状态：失败保留 + 可重试（修复前失败即永久失去落盘机会）。 - 45 `flush()` 先入链再报告后台错误（修复前一次后台失败会让之后每次 flush 直接抛错、 数据永远等不到落盘）；被重试修复的失败进 `getBackgroundWarnings()`（可见但不误报失败）。 - 47 `MergeIterator` 胜出来源的补充推迟到下一次 `next()`：提前终止不再多算一条。 - 49 `compacting` 由单 boolean 改为按层集合（跨层触发不再被静默丢弃）。 - 50 compaction 不再"先 splice 整层再合并"（窗口内该层对读者可见）； 被取代的 SSTable 进"退休表" + 读者 epoch，等更早读者退出才物理删除。 - 51 底部层原地合并回收墓碑（删除密集场景空间不再无界增长）；"整层只剩墓碑" 有专门分支 （修复前会读 `merged[0][0]` 抛 TypeError，compaction 永久失败）。 - 55 flush 与 compaction 拆成两条链，checkpoint 只落 memtable；删除引擎层全部 `prefetch*`/`drainChain` 依赖，改为"快照 + 结构版本乐观重试" （版本号同时覆盖 levels 与前台 memtable/frozen 的变化）。 - 读路径自洽：介质读故障抛 `ARIA_SSTABLE_READ_FAILED`，不再折叠成"文件不存在"误删元数据。 三、WAL - LSN 全库单调（manifest 记高水位）；按水位删除旧分片（`planKeepFrom` → 提交 → 再删除）。 - **分片号只增不减**：修复前全量截断后重置为 0，会与 manifest 记录的 startSegment 错位， 实测造成两个方向的损坏（删掉的行复活 / 已确认写入丢失，见随机压力套件）。 - 分片空洞（含前缀缺失）显式报 `ARIA_WAL_GAP`，不再静默丢弃尾部。 四、其它 - `sstable.ts` 三份解析循环合并为 `iterEntries()`，越界策略统一。 - `vacuum()` 返回真实压缩层数（修复前硬编码 6 且底部层永不压缩）。 - `close()` 加 try/finally（落盘失败也必须释放后端/锁并复位状态）。 - `getRecoveryReport()`：{droppedSSTables, dataLossSuspected, walGaps, legacyImported, manifestFallback} —— "自愈了什么、有没有真丢数据"成为可读返回值。 五、验证 - 新增 `tests/v080-b6-single-commit-point.test.ts`（63 项，含 manifest 严格校验表驱动 25 例）。 - 新增 `scripts/mutation-b6.py`：22 项变异验证（把每个修复回退到修复前行为，对应用例必须失败）， 全部被拦住 —— 这批用例不是陪跑。 - 常规套件 1935 通过 / 91 套件；覆盖率 90.34 / 82.16 / 94.06 / 93.23（阈值 90/82/94/93）； e2e 14/14；重型套件 4 套件 27 项全绿。	2026-09-15 10:29:03 +08:00
thzxx	97b9fa486d	fix(A38/A39): 页面化路径真正压缩 + compressLZ4 去除二次复杂度（含测试介质目录语义修正） ... A38 `compression` 在页面化路径上被静默忽略 压缩只写在"整 value 存一个 backend value"的分支里，而 `save()` 在页面化 分支**提前 return** —— `pageStorage` 默认自动（OPFS 后端下为 true）， 于是 `compression: true` 在默认配置下完全无效且无任何提示。 修法：`compression` 传入 `PageSSTableStore`，在**切页之前**整体压缩 （压缩率优于逐页压缩），加载时对称解压。 连带修正一个会静默损坏数据的接口问题：`SSTableMeta.totalSize` 的语义是 "页面里存了多少字节"，加载时按它截断 —— 压缩后必须写**压缩长度**。 为此 `SSTableStore.save` 改为返回 `{ storedSize }`，两处 flush 流程与 整 value 路径都用它回填 totalSize（写未压缩长度会让压缩数据被 0 填充撑大）。 为什么此前没被发现：既有测试只断言"压缩后能读回来"，而"根本没压缩" 同样能正确读回 —— 断言太弱。新用例改为**结构性断言**： 开启压缩后落盘字节数必须显著下降（>5×），与实现细节无关。 A39 `compressLZ4` 匹配搜索为 O(n²) 旧实现逐字节向前扫描最多 65535 个候选位置、每个位置再逐字节比较 —— 在低压缩率数据上退化为二次复杂度。实测 60KB 伪随机输入耗时 **2345ms**； 而 SSTable 页/日志段正是几百 KB 到几 MB，属于普通写入路径上的真实卡顿。 修法：改为 LZ4 标准的 **4 字节哈希链**（`head[]`/`prev[]`，单点最多 `MAX_CHAIN=32` 次探测）→ 实测 6ms（约 390×）。 **输出格式完全不变**，既有落盘数据无需迁移；旧实现保留为 `compressLZ4LinearReference` 并作为测试对照物（证明两者可互解）。 另加"全字面量"兜底：任何异常都产出合法可解压的流（数据正确性优先于压缩率）。 测试介质修正（同源发现，影响所有 OPFS 多库场景） `installOPFSMock` 把 `getDirectoryHandle(name)` 的 `name` **丢弃**， 所有库共用一棵扁平文件树。实测：`open('db-alpha')` 建表后 `open('db-beta').getTableNames()` 返回 `["alpha_only"]`。 真实 OPFS 下 `OPFSBackend.open(name)` 是 `root.getDirectoryHandle(name)`， 因此 mock 现在实现真实的**目录语义**，并提供 `dir(dbName)` 视图让测试与 生产代码使用同一个 API（此前的 `listKeys/createFile` 是根目录假 API， 两个依赖它的用例已改为目录视图）。 验证：新增 tests/engine/aria-compression.test.ts（12 项，含 1MB 大输入与 6 组格式兼容用例）；两处修复都做**变异验证**：回退 A38 的接线 → 页面化压缩 用例失败；回退 A39 到线性实现 → "60KB < 1s" 用例失败（实测 2397ms）。 全量 89 套件 / 1742 测试通过；typecheck、lint、build 零错误/零告警；dist 已重建。	2026-09-15 01:52:57 +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
thzxx	7c7ecb8b1d	test: 补齐 aria-cache 测试的类型标注（getOversizedCount，上一提交遗漏）	2026-09-14 21:53:56 +08:00
thzxx	074afd3f1e	fix(A8 + LSM 读自洽): 行所有权根治 + 读取路径不再依赖 prefetch ... A8 行引用泄漏（调用方改查询结果即改写存储） 实测：rows[0].tag = 'HACKED' 后，tag='HACKED' 与 tag='x' 两条索引查询都返回 0 行 —— 行与索引失配、该行永久查不出来；嵌套 json 值同样按引用共享。 Aria 因走反序列化路径反而幸免，又形成跨引擎差异。 根治：在 IStorageEngine 契约层写入**行所有权约定**（engine/interface.ts） —— 读出的行是副本、写入接收的行也是副本；新增 cloneRow/cloneRows （优先 structuredClone，退化路径处理 Date/嵌套对象/二进制）。 Memory/KVStore/Hybrid：find、findStream、getRow 全部返回副本。 Aria：getAllRows 此前只做 `{ ...value }` 浅拷贝（嵌套 json 仍共享引用）， 改为深拷贝；find/findStream 返回副本。 实测四种引擎：修改返回值后重读不变、索引两条查询均正确。 LSM 读取自洽（审计 P1-1：缓存未命中 = 静默丢数据） 此前 loadSSTableReader 缓存未命中返回 null，而所有调用方都是 const reader = this.loadSSTableReader(meta); if (!reader) continue; 于是**未命中就静默跳过整个 SSTable**。实测：缓存上限 4KB 而 SSTable 更大时， 300 行只能查回 59 行，且不报错。 同时"读路径必须先 prefetch"这个隐式约定，是每次读都要 drainChain + prefetch 的原因（性能悬崖的另一半）。 根治：LSM.get / rangeScan / rangeScanLazy 改为 async，未命中即 `await sstableStore.load()` 回源 + CRC 校验（损坏则自愈清理 meta）， 只有数据确实不存在才返回 null。checkUniqueSync 相应改名 checkUnique 并 async （原命名正是因为依赖 prefetch 约定）。引擎侧 12 处调用点补 await。 附带修正的缓存语义： - tryCacheSSTable：单个 SSTable 超过缓存上限时标记为常驻（pinned）， 不参与驱逐 —— 驱逐它等价于静默丢数据；内存上限因此是 cacheLimit + 单个最大 SSTable，已在代码与测试中明确。 - trimCache 跳过 pinned 条目（此前会把全部缓存一次性清空）。 - 新增 getCacheSize/getCacheLimit/getOversizedCount/setCacheLimit 访问器 （测试此前直接读私有字段 cacheSize/cacheLimitBytes —— 那是 TS 错误， 只因测试不做类型检查才没暴露）。 queryStream async 回调 此前用 constructor.name === 'AsyncFunction' 判定，对"普通函数返回 Promise" 完全失效（Promise 被静默丢弃）。现改为双条件识别并走物化路径逐行 await， async 回调被真正等待。 测试契约修正： - aria-cache：'缓存大小受上限约束' 在极小缓存下是不可成立的契约，改为断言 真正重要的不变量（数据完整；可装入时受上限约束），并新增"超大 SSTable 常驻" 用例；'缓存驱逐后全表扫描仍返回完整数据' 保留 300 行断言（此前会失败）。 - hybrid：磁盘引擎标签断言从 indexeddb（v0.6.0 已移除）改为 opfs。	2026-09-14 21:43:21 +08:00
thzxx	0dba1abf2a	test(P0): v0.8.0 验证基座与工程门禁根治 ... 工作流 C-1 / C-3 前半 + 测试代码类型检查。 【故障注入基座】新增 tests/helpers/storage-harness.ts + faulty-backend.ts - TransactionalFileStore：忠实 OPFS 提交语义（close 才可见）+ 字节级故障注入 （failNextWrite/Append/Delete、truncateAppendTo 撕裂写、crashPending 真崩溃） - 删除旧 opfs-mock：读返回内部引用、keepExistingData:false 不截断、close 空实现 导致"提交前可见"等真实缺陷无法被测出（31 个测试文件迁移至新 harness） - 删除 aria-opfs-backend 内的第三份重复 mock（含从未被断言使用的 writeCalls 死代码 与 entry.content.subarray 恒等分支） - FaultyBackend：包装任意 IStorageBackend 注入故障；crash() 明确区别于 close() （后者是优雅停机，会刷完写队列 —— 这正是此前所有"崩溃恢复"测试的真相） - 16 条基座自测证明注入真的生效（含 close 不能当崩溃的对照组） 【覆盖率口径】jest.config.cjs - 移除 '!src/**/index.ts'（该 glob 把 AriaEngine 主实现等 15 个实现文件整体 排除出统计，与 v0.2.6 曾承认过的问题同源），改为只排除纯类型声明文件并附理由 - 新增 coverageThreshold 门禁（此前完全不存在） - 真实基线：语句 90.66% / 分支 82.94% / 函数 94.36% / 行 93.43% - 修正 testMatch 使 tests/helpers 下的测试可被发现 【测试代码类型检查】tsconfig.test.json + npm run typecheck:tests - 修复 103 个测试代码类型错误（此前 babel 剥离类型 + tsconfig 排除 tests，全部隐藏） - 新增 tests/helpers/assertions.ts：nonNull/decode/rows/object/engineMethod/expectCode 以断言收窄替代 as any - 消除 21 个 lint warning（含 v043-hardening 中定义后从未调用的 mockOPFS 死代码） - parser.test.ts 12 处 toBeDefined() 空断言升级为结构断言（并新增 AND/OR 优先级用例， 当前红灯，对应总账第 11 项，将在工作流 A 修复） 【版本契约】新增 tests/version-contract.test.ts - 校验 src VERSION / package.json / dist 三者一致，替代两处硬编码版本字面量 【CI 门禁】.gitea/workflows/ci.yml - lint 去掉 continue-on-error（此前永远不让 CI 变红） - 新增 tests 类型检查、--coverage 覆盖率门禁、dist 与源码同步校验 - 版本 0.7.4 升至 0.8.0	2026-09-14 21:03:06 +08:00
thzxx	05e6823bf1	fix: v0.7.2 语句级原子性 + 事务 DDL 拒绝 + 约束/绑定硬化 — 6 项修复 + 43 回归 + CI 重型套件串行 ... - UPDATE 语句级部分提交（P1，四引擎）：两阶段全量预检后执行，批内唯一互查， 任何一行失败整句不执行（aria 场景 WAL 与内存不再错位） - 事务内 ALTER/CREATE INDEX/DROP INDEX 残留（P1）：Memory/KVStore 显式拒绝 （对齐 Aria），createTable/dropTable 保持可回滚 - SET NULL 级联绕过 required 约束（P1）：预检阶段整体拒绝 FOREIGN_KEY_VIOLATION - bindParameters 注释误判（P2）：行注释/块注释中的 ? 与引号不再参与绑定 - 未闭合字符串静默接受 → lexer 抛 PARSE_ERROR；未知 where 操作符抛 QUERY_ERROR - UPDATE undefined 覆盖列值 → 语义化为不更新（null 仍置空） - Hybrid 写穿透非原子（P1）：磁盘失败自动重载内存对齐磁盘再抛原错误 - CI：Run tests 拆常规并行 + 重型串行（runInBand），重型测试超时余量提升， 性能护栏 kv 120→240s / opfs 150→300s（仍拦截悬崖回归） - 测试 1155 → 1198（74 套件），覆盖率 89.82% 保持	2026-08-13 15:31:16 +08:00
thzxx	f97c5a6001	fix(P2): v0.6.3 原子性/一致性/资源治理 — 8 项修复 + 12 回归 ... - KVStore 混合写单记录原子：新增 writeBatch（put+delete 同一条日志记录）， KVStoreEngine 全部混合写路径统一（兑现真原子宣称，崩溃无新旧行并存） - WAL full 模式写入失败抛错（此前 console.warn 吞错 → 崩溃即丢且无感知） - MemoryEngine SET NULL 级联索引残留：复用 removeIndexEntries（消除虚假 UNIQUE_VIOLATION） - delete 级联两阶段：先全量 RESTRICT 预检（沿 CASCADE 链递归）再执行，无部分级联 （Memory/Aria 对齐） - BufferPool 驱逐同步清理 pages Map（EvictionManager onRemove 回调，内存预算真实生效） - MVCC commit 清理已提交版本（版本链仅作事务内 undo，消除行数据双份常驻） - LSM.flush 重复入链修复（入链即置空 immutable）+ frozenMemtables 可见性时序 - rollbackToSavepoint 重建受影响表二级索引（消除过期索引条目） 测试 1114 → 1126（71 套件）；行覆盖率 89.7%；版本 0.6.3	2026-08-13 10:30:39 +08:00
thzxx	a91ac368e2	ci: 放宽 10 万行性能护栏（kv 60s→120s / opfs 90s→150s）— CI debian runner 慢 2~3 倍且 maxWorkers=2 并行重型测试，84s 为健康性能（修复前悬崖 353s）；护栏仍能拦截悬崖回归	2026-08-11 09:02:35 +08:00
thzxx	5c6011d487	fix(P0): 生产矩阵审计暴露 2 个崩溃恢复丢数据 bug — ① FileManager 页面 id 崩溃回退（allocatePageIds 后 saveMeta 前中断 → nextPageId 回退 → 恢复期页面复用被 compaction 误删，kv 2万行+加密崩溃丢75%）：init 以现存最大页面 id+1 为准；② LSM.flush 剩余数据与 compaction 并发写 meta（产物 saveMeta 被覆盖成孤儿 → 优雅关闭重开丢75%）：剩余落盘挂链串行。新增 13 组合矩阵审计（后端×特性×功能全量验收）	2026-08-10 21:30:49 +08:00
thzxx	d83910832e	perf(P1): 批量插入性能悬崖 — insert 循环内逐行 prefetchKeys（每行 await drainChain 排空后台链），compaction 在链上数秒时每行阻塞数秒 → kv 后端 10 万行插入 353s；改为批级预加载本批 PK 一次，实测 353s→12.5s（28 倍）/ opfs 25s；新增 kv/opfs 双后端 10 万行回归（性能护栏+索引完整+崩溃恢复），aria-cache 测试同步适配显式 flush	2026-08-10 20:14:57 +08:00
thzxx	34225a86b3	fix(P0): SSTable rangeScan 尾块漏读 — 索引块记录块尾 key 但二分按块首语义定位，endKey 落在块尾时下一块被排除导致二级索引查询丢数据（5万行丢106~771条）；endBlockIdx 多扫一块 + 4 个 sstable 边界回归 + 重建二级索引大数据量回归（含崩溃恢复）。附带：checkpoint 同步 flush 二级索引 LSM（P1）、kv 后端页面化 + SharedMemoryBackend chunk 化、生产负载验证测试	2026-08-10 18:18:50 +08:00
thzxx	25bab0f9aa	feat: v0.6.1 — AriaEngine 可选自研 KVStore 后端（storageBackend: 'kv'）+ KVStore APPEND 日志类型 + 10 个 aria+kv 集成测试 + 文档全量同步	2026-08-10 14:52:38 +08:00
thzxx	a9e1a281d3	fix: v0.6.0 复查修正 — KVStore 快照损坏水位 bug（metaSeq 误跳日志）+ 快照损坏测试盲区修复（此前篡改未生效）+ metaSeq 回归测试 + KVStoreEngine 真实浏览器 e2e（3 用例）+ 版本/配置文档校准	2026-08-10 14:11:44 +08:00
thzxx	24b3ca1079	release: v0.6.0 — 完全移除 IndexedDB，自研 KVStore 事务存储引擎（多key原子写/快照日志恢复/CRC自愈）+ KVStoreEngine + 旧库迁移工具 + 10万级压力验证 + 崩溃注入e2e	2026-08-10 13:56:04 +08:00
thzxx	334067d89e	release: v0.5.1 — 存储后端生产级硬化（CRC-32/全库加密/WAL分片/页面化存储/多标签页锁/e2e）+ 深度审查修复（假实现接线/死代码清理）	2026-08-10 12:07:00 +08:00
thzxx	fda3f1ad34	fix: CI Node 18/20 下 aria-crypto 失败 — SubtleCrypto 跨 realm ArrayBuffer 兼容 ... - crypto.ts encryptPage/decryptPage 改传 TypedArray 视图(ArrayBuffer.isView 检查跨 realm 可靠) - jest.setup.js structuredClone polyfill 用跨 realm toString 标签检查 (修复 fake-indexeddb 存储 ArrayBuffer 被 JSON 破坏成 {} 的问题) - 新增 SSTable 加密真实路径测试(加密落盘→重载解密, 8 个测试) - aria/v025 固定 db 名改随机(fake-indexeddb 真实持久化后防表残留冲突) - Node 18/20/22/24 全矩阵 837 测试通过	2026-08-08 11:07:35 +08:00
thzxx	d544501e1c	release: v0.3.2 — 质量加固 + SQL扩展 + 表达式 + 并发同步 ... v0.2.6 质量加固: - 修复 AriaEngine 二级索引 SSTable 互相覆盖(命名空间隔离) - 修复 LSM 多版本读取顺序错误 + MergeIterator 取最新来源 - 重写 LZ4 压缩器(往返一致性 + 缓冲区溢出) - sstableCache LRU 上限 + 预加载兜底(BufferPool 配置生效) - 修复 React/Vue 集成 import type 运行时 bug + exports 子路径 - 新增 38 个测试(LZ4往返/Crypto/集成), 删除伪测试 v0.3.0 SQL 功能扩展: - 多语句 parseAll + 事务语句 BEGIN/COMMIT/ROLLBACK - INSERT INTO ... SELECT + UNION/UNION ALL + EXISTS 关联子查询 - CREATE/DROP INDEX 五引擎实现 + 别名 WHERE 修复 - benchmark 页面 + 36 个新测试 v0.3.1 表达式与性能: - CASE WHEN 表达式(SELECT 列/WHERE/聚合) - JOIN + 关联子查询逐行绑定 - WAL 批量组提交(写放大 O(N)→O(1)) - 修复 pending frozen 可见性 + flush 缓存竞争 v0.3.2 并发: - CASE WHEN 用于 WHERE/聚合 + JOIN 哈希连接 - 多标签页同步(multiTabSync + BroadcastChannel) - IndexedDB schema 持久化(reopen 后表结构恢复) - 修复 where-matcher 顶层 $not - 修复 CJS 产物 .js 被 ESM 解析(exports 空) — .cjs 后缀 + exports 修正 - 836 测试 / 44 套件 / 81.0% 覆盖率	2026-08-08 10:41:30 +08:00
thzxx	4c26882caa	release: v0.2.4 — 701 tests, 32 suites, 零死代码, 零空壳, 全模块接入	2026-07-27 22:18:08 +08:00
thzxx	d33f4ab3b0	test: OPFSEngine 12项mock测试 + Schema约束5项测试 → 543 passed	2026-07-27 21:34:12 +08:00
thzxx	4a3feac9ea	release: v0.2.3 AriaEngine 引擎加固 — RB-Tree fixDelete/LSM SSTable缓存预热/LZ4格式修复	2026-07-27 21:22:29 +08:00
thzxx	620cd11521	fix: 修复 CI 卡死 + LZ4/SSTable/Checkpoint 多项 bug — 526 测试全通过	2026-07-27 20:28:23 +08:00
thzxx	f84673e519	feat: v0.2.0 AriaEngine 自研存储引擎 ... - 新增 AriaEngine: LSM-Tree 页面式存储引擎，19 个模块，~3500 行 TS - page/: Slotted Page 格式 (header/slot/tuple/format) + CRC32 - buffer/: Buffer Pool (LRU 缓存 + 驱逐策略) - index/: LSM-Tree (MemTable 红黑树 + SSTable + Bloom Filter + Merge Iterator) - wal/: WAL 日志 (二进制格式) + Checkpoint 管理 - transaction/: MVCC 版本链 + 快照隔离 - store/: IndexedDB / Memory 双后端抽象 - compression/: LZ4 页面压缩 - 完整持久化: Schema 自动保存、SSTable 元数据管理、WAL 恢复 - 事务感知 CRUD: insert/update/delete 在事务中缓冲到 snapshot - mode: 'aria' 激活自研引擎 - 新增 7 个测试文件，测试数 318 → 524，套件 20 → 27 - aria-page.test.ts (32 tests): Page 格式单元测试 - aria-index.test.ts (26 tests): Bloom Filter + MemTable - aria-sstable.test.ts (9 tests): SSTable Builder + Reader - aria-buffer.test.ts (25 tests): LRU + Eviction + Buffer Pool - aria-wal-mvcc.test.ts (22 tests): WAL 编解码 + MVCC 事务 - aria-compress.test.ts (11 tests): LZ4 + Merge Iterator - aria.test.ts (80 tests): AriaEngine 集成 + 边界测试 - Bug 修复: LRUList size 跟踪、WAL 缓冲区越界、ColumnEncoding 导入 - 全面更新 README.md + site/ 站点文件 (index/docs/demo)	2026-07-27 16:40:29 +08:00
thzxx	e2a590c5b1	feat: metona-sqlark v0.1.12 — 前端TypeScript关系型数据库 ... - 4种存储引擎：Memory / IndexedDB / OPFS / Hybrid - 完整SQL支持：SELECT/INSERT/UPDATE/DELETE/JOIN/GROUP BY/HAVING/DISTINCT - Query Builder链式API + TypeScript泛型支持 - 聚合函数：COUNT/SUM/AVG/MIN/MAX - 事务、插件系统(14 hooks)、发布订阅、数据迁移、导入导出 - React/Vue框架集成 - 264个测试用例，93.46%覆盖率 - 零运行时依赖	2026-07-26 15:00:01 +08:00