37 Commits

Include renames

Author	SHA1	Message	Date
thzxx	799560ea05	docs(G6): 宣称与实现一致性收口 —— priority 真正生效、MVCC/backup/引擎数/打包 全部对齐 ... 独立核验（12 条宣称逐条对源码验证）发现 5 处**硬伤**与 2 处**数字过期**， 本提交按"能改代码就让宣称成立、改不动就如实描述"的原则全部收口。 让实现符合文档（2 处）： 1. **插件 priority 此前不生效** — `register()` 虽按 priority 插入数组，但 `install()` 在 register 内**立即**执行，因此 install 与钩子顺序 = config 数组 顺序（实测 priority low=1/high=100/mid=50 时钩子按 low→high→mid 触发， 只有 `getPlugins()` 是 high,mid,low）。而 README/CONTRIBUTING/constants 一直宣称"越大越先执行"。 现在 Core 注册前按 priority **稳定降序**排序（同优先级保持数组顺序）， install 与钩子都按优先级执行 → 宣称成立。新增 `tests/v080-plugin-priority.test.ts` 锁定 install 顺序、钩子顺序、稳定性、缺省值。 2. **连接池静态方法不在类型系统里** — `MetonaSqlark.connect/disconnect/ disconnectAll/getActiveConnections` 由 connection-manager 用 `as unknown as Record<string, unknown>` 注入，README 的连接池表格在 TypeScript 下全部 TS2339。现在在类上声明为可选静态成员，注入处去掉断言。 如实描述（3 处）： 3. **MVCC 快照隔离**（README 三处 + 实现对照）— `snapshotLsn` / `prevVersion` 只写不读，事务读走 `txnSnapshot`+LSM，commit 即清理版本链，并发 `beginTransaction` 抛 `TX_ACTIVE`。改为"快照回滚（事务串行，非 MVCC 隔离）"， 并在 README 架构图与维护语句表里同步措辞。 4. **"存储引擎（5 种）"** — 实际是 4 种模式 + 3 种后端，引擎类只有 4 个 （Memory / KVStore / Hybrid / Aria），OPFS 是后端而非引擎。标题与条目已改写， 并写明"`disk`/`hybrid` 恒用 KVStore"。 5. **`diskEngine` 生效范围** — 仅 `mode:'aria'` 生效；`constants.ts` 的注释 此前写成"仅 mode='disk'|'hybrid' 时生效"（正好写反），已改正；README 配置表、 快速开始示例与 Aria 示例同步标注。 数字口径统一（可复现）： - 测试 1872（90 套件）+ 14 e2e，另 4 个重型套件在独立 CI job 串行运行； - 覆盖率 语句 90.43% / 分支 82.21% / 函数 94.27% / 行 93.44%； - README 明确写出**产出这些数字的完整命令**（与 CI 常规 job 一致）， 并要求改动覆盖范围/阈值时同步更新表格（G5）。 - CHANGELOG 0.8.0 条目与 site 首页/文档页同步。 另修 **CONTRIBUTING 的钩子契约**：明确写出"返回值被忽略（不能取消/改写）、 就地改参数在 Table API 生效、抛异常可取消、SQL 路径的 beforeInsert 收到副本" —— 此前只写 "allow intercepting"，容易被理解为返回值可改变行为。 验证：全量 90 套件 / 1872 测试通过（+4 重型套件）；覆盖率四项均高于阈值； typecheck(src+tests)、lint、build 零错误零告警；e2e 14 项通过；dist 已重建。	2026-09-15 08:06:23 +08:00
thzxx	2c945ee05a	feat(B-5): 输出列序号 + 分隔标识符语义统一 ... 两个相关缺陷： ① **输出列序号不被支持**（SQL 标准特性） `ORDER BY 1` / `GROUP BY 2` 此前直接 `PARSE_ERROR: Expected identifier, got "1"` （实测）。这在手写 SQL 与 UNION 里很常用 —— 各分支输出列名可能不同，只能按 序号引用。序号含义依赖 SELECT 列表，故 parser 只保留数字文本，由 executor 在拿到列表后解析。 规则（与 SQLite/标准一致）：裸数字在范围内 → 位置；越界 → QUERY_ERROR （不说"未知列"，问题出在位置而非名字）；`GROUP BY <序号>` 指向聚合表达式 → QUERY_ERROR（按聚合值分组语义上不成立）；`ORDER BY 0` / `1.5` → PARSE_ERROR。 ② **分隔标识符（`"1"`）在投影期被当成常量** `CREATE TABLE q ("1" STRING ...)` 后 `SELECT "1" FROM q` 返回 `{"1": 1}` （**字面量 1**），而 `SELECT *` 返回正确的 `{"1": "z"}` —— 同一列两种结论。 根因：parser 把 `"1"` 的引号丢掉，投影期的"裸数字 = 常量列"子句就把它吃了。 修复的关键设计（一致性是这里唯一的难点，实测踩了四次漂移）： **引号只在"解析 → 执行"的边界脱去，且必须在同一处、对同一批引用统一处理。** parser 必须保留引号才能区分"名为 1 的列"（`"1"`）与"常量 1"（`1`）； 而校验/取值/排序/分组必须用真实列名。此前"校验用裸名、投影用带引号名"两套规则 导致 `1` 与 `"1"` 两个键并存。现在统一在 `normalizeUnprefixedReferences` 与 `projectRow`/`projectColumns`/`resolveGroupKeyValue` 的对应分支脱引号， 并新增可复用的 `unquoteIdentifier`。 同时修正 `projectColumns`（where-matcher，被四个引擎共用）：此前"找不到列就不产出 键"，现在支持分隔标识符与 `别名.列` 的唯一后缀匹配；"是否未知列"仍由 executor 的 `assertProjectionColumnsExist` 判定并报错，投影层不做静默兜底。 验证：新增 tests/v080-output-ordinals.test.ts（64 项：序号四引擎 40 + 分隔标识符 四引擎 24），覆盖 DESC/多键/LIMIT+OFFSET/UNION/别名共存/越界/非法序号/ WHERE 与 GROUP BY 引用分隔标识符/优先级。 全量 91 套件 / 1870 测试通过；typecheck、lint、build 零错误零告警；dist 已重建。	2026-09-15 07:39:03 +08:00
thzxx	3983aae426	feat(B-4): 统一表达式求值 —— CASE 结构化解析（消除正则切分整类缺陷） ... 修复前 `parseCaseExpression` 用正则切分 WHEN/THEN/ELSE，不认字符串字面量与嵌套， 实测出三类错误结果： ① **嵌套 CASE 返回字符串残片** `CASE WHEN n>10 THEN CASE WHEN n>25 THEN 'huge' ELSE 'big' END ELSE 'small' END` → 实测返回 `"big' END ELSE 'small"`（正则把嵌套 CASE 的 ELSE 当成自己的分支 边界，残片被原样返回给用户）。修复后正确返回 huge/big/small。 ② **条件引用不存在的列时静默错值** `CASE WHEN nope > 1 THEN 'x' ELSE 'y' END` → 每行都是 'y' 且**无任何报错** （`cond = null` 表示"解析失败"→ 静默跳过分支），而同一个 nope 写在 WHERE 里 会正常抛 COLUMN_NOT_FOUND。修复后统一报 COLUMN_NOT_FOUND。 ③ **`GROUP BY CASE ... END` 完全不可用** → `COLUMN_NOT_FOUND Unknown column "CASE WHEN n>10 THEN 'big' ELSE 'small' END"` （分组把 CASE 原文当成列名）。而"按条件分组"是 SQL 最常见的分析写法之一。 修复后正常输出 `[{band:'big',c:2},{band:'small',c:2}]`。 实现（新增 `src/query/expression.ts`）： - 复用 `sql/lexer` 的 token 流做**递归下降**（天然支持嵌套；字符串里的 WHEN/ELSE/THEN 由词法层天然隔离，不可能被当作切分点）； - 条件按源码切片后交给与 WHERE **完全相同**的 `parseWhereCondition` —— 语义同源； - 结果表达式显式支持字面量/列引用/嵌套 CASE，无法识别的**抛 NOT_SUPPORTED** （不再把原文当字符串返回）； - 解析结果记忆化（同一表达式在 N 行上只解析一次）； - 新增 `assertCaseColumnsExist`，在**分组/聚合之前**按 schema 校验 CASE 里引用的列 （时机很关键：分组会把行替换为"分组键+聚合值"，此后任何基于行的校验都会 误报未知列 —— 这一点在实现中踩到并已修正）。 顺带修掉的**词法层**缺陷：`Token.position` 语义按 token 类型不一致 —— `readString` 用 `position + 1`（指向引号**之内**），`readIdentifier`/`readNumber` 用 `position - len`（指向首字符）。任何"按 position 切片"的调用方都会对字符串 切错一个字符（实测 `'big'` 被切成 `"big'"`，导致 CASE 全部报 NOT_SUPPORTED）。 现统一为"token 首字符在源码中的下标"，并用"从 position 重新词法化应得到同一 token"作为可判定判据加入回归测试。 验证：新增 tests/v080-case-expression.test.ts（54 项：词法层 2 + 解析层 8 + 求值层 5 + 列校验 2 + 四引擎端到端 37），并做**变异验证**：去掉嵌套 CASE 感知后 7 项立即失败（含四引擎的端到端断言），恢复后全绿。 全量 91 套件 / 1807 测试通过；typecheck、lint、build 零错误零告警；dist 已重建。	2026-09-15 07:26:20 +08:00
thzxx	bf93ec5251	fix(A41): DDL 的 WAL 意图必须先于生效 + ALTER 结构变更可崩溃恢复（A40 未复现，固化为护栏） ... 实测确认的缺陷：**DDL 的 WAL 意图记录写在生效之后**，而 WAL 是崩溃后唯一能重放 的结构权威 —— 于是它恰恰是最后才写的： - `dropTable('other')` 删完 LSM 与 schema 后崩溃（WAL 尚无 DROP 记录） → 重开 `tables = ["t","other"]`，且 other 的行数据完好：**DROP 被静默撤销** （用户以为删掉了）； - `alterTable` **完全不写 WAL**：先改内存 schema、必要时建索引（可能因存量 重复值抛错），最后才 persistSchemas —— 中间抛错就留下"内存已加列、磁盘没加" 的分裂状态，崩溃则结构变更整体丢失。 变异验证：去掉 ALTER 回放后，`ADD tag` + `ADD tag2` 两列在重开后**都消失** （实测 `after reopen columns: ["id"]`）。 修法（结构上唯一正确的顺序）： **先写 WAL 意图并刷盘 → 再改内存 → 最后落盘 schema** WAL 回放是幂等的（CREATE 对已存在的表跳过、DROP 对不存在的表是空操作、 ALTER 用变更后的完整 schema 覆盖），因此先写 WAL 一定能收敛： 崩溃于 WAL 之后生效之前 → 重放生效；崩溃于生效之后 → 重放幂等。 新增 `WALRecordType.ALTER_TABLE = 10`（含变更后的完整 schema）与统一入口 `appendDDLRecord`（两条 DDL 路径共用顺序与刷盘策略，避免再次单点漂移）。 测试可观测性：`AriaEngine` 无法注入存储后端 —— 而 `this.backend` 在 `open()` 里被 WAL、FileManager、SSTableStore 一起捕获，事后替换只会替换一部分 （实测：替换后 WAL 仍写旧后端，于是"崩溃"根本没覆盖 WAL 路径，探针得出假结论）。 新增 `AriaEngineConfig.testBackend`（仅测试用）作为注入点。 关于 A40（审计记录为"close() 截断 WAL 并把未提交写入落盘 → 重开后幽灵行"） 经探针**未复现**：事务中 close 后重开只看到已提交行；事务中 DDL 抛 NOT_SUPPORTED；close 后 rollback 抛 TX_NONE；二次 close 幂等。 按项目原则不"修"不存在的问题，而是把这些**已正确**的行为固化为护栏。 验证：新增 tests/v080-aria-ddl-atomicity.test.ts（11 项：4 项顺序不变量、 4 项崩溃恢复、3 项生命周期护栏）。顺序断言用"记录持久化顺序的后端"实现 —— 那是**顺序**性质，OPFS mock 只暴露最终状态，测不出来。 四处修复均做变异验证。全量 89 套件 / 1752 测试通过；typecheck、lint、build 零错误零告警；dist 已重建。	2026-09-15 02:20:27 +08:00
thzxx	567d150257	feat(A37): 未限定列可作比较操作数 + WHERE/JOIN ON 列引用存在性校验 ... 两个此前互相纠缠的缺陷（PLAN §5 #35/#37、§3 根因 7 的最后一块）。 ① 未限定列不能作比较操作数（语法层） parser 只把 `a.b` 形态当列引用，裸标识符一律走字面量解析，于是： WHERE x = y → PARSE_ERROR: Expected value, got "y" ON k = k → 同上 列对列比较被迫写成 `WHERE t.x = t.y` —— 而多表 JOIN 里未限定列恰恰是最 自然的写法（`ON user_id = id`）。 修法：操作数位置上的 IDENTIFIER **必然是列引用**（字面量各有自己的 token 类型：NUMBER/STRING/TRUE/FALSE/NULL），这一条不需要猜测。 * 排查记录：这里试错了两次。起初用 peekToken 判"下一个是否运算符"， 实测仍报错 —— 因为进入该分支时运算符**已被 parseComparisonOp 消费**， `peek` 是 EOF/AND 而非运算符。最终按"位置"判定，不再依赖 lookahead。 ② `$col` 引用到不存在的列 → 静默空集（语义层） 投影侧早有列存在性校验，WHERE 侧一直没有：`$col` 取不到值 → UNRESOLVED → 比较判 UNKNOWN → **所有行被过滤且不报错**。实测修复前： SELECT id FROM t WHERE id = oops → [] SELECT id FROM t WHERE id = t.oops → [] SELECT id FROM t WHERE x = nope → [] SELECT ... FROM l JOIN r ON l.k = r.nope → []（连接不上任何行） 用户看到的是"没有数据"，与"列名拼错"完全无法区分。 修法：新增 `validateWhereColumns`（WHERE 的键位 + `$col` 值位，含 `$and`/`$or`/`$not` 内部）与 `validateJoinOnColumns`（ON 两侧归属判定）， 两者共用同一遍历实现。 契约变更： - 拼错的列名 → `COLUMN_NOT_FOUND`（此前 PARSE_ERROR 或静默空集）； - JOIN 的 WHERE 里裸写两表同名列 → 歧义报错（SQL 标准要求限定）； - `ON k = k` 这类裸写法仍按"取主表列"解释（不因两表同名而拒绝， 否则会把常见等值连接写法判为错误）。 附带修正：`schema.ts ↔ validation.ts` 的**循环依赖**（rollup 构建告警 "Circular dependency"）。`checkFieldType` 的实现搬到 validation.ts（唯一校验 定义），schema.ts 重新导出以保持公开 API —— 依赖方向改为单向 （validation ← schema）。循环依赖在 ESM 下求值顺序不稳定，是难查的运行时陷阱。 验证：新增 tests/v080-column-resolution.test.ts（4 引擎 × 8 项，共 32 断言， 期望值全部逐个实测得出）；tests/v080-correlated.test.ts 的"裸 x = y 为 PARSE_ERROR"用例改为断言两种写法等价。 全量 86 套件 / 1697 测试通过；e2e 14 项通过（真实 Chromium + OPFS）； typecheck(src+tests)、lint、build 零错误/零告警；dist 已重建。	2026-09-15 01:21:58 +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	2844a0617c	docs: site 站点全量同步 v0.7.4 — 首页徽章/统计（1304测试 76套件 90.1%）+ 流式真惰性说明、API 文档补写语句子查询与 DROP INDEX UNIQUE 语义 + v0.7.4 里程碑、错误码表补 COLUMN_NOT_FOUND/INDEX_NOT_FOUND、演示/基准版本标注、README 已知限制章节、dist 重建（VERSION 0.7.4）	2026-08-15 15:08:38 +08:00
thzxx	50468b9b0e	fix: v0.7.3 数据正确性与边界窗口收尾 — INSERT 语句级原子（三引擎+Aria PK 批内重复）/ 索引列 IS NULL 恒空 / delete RESTRICT 破坏索引 / queryStream 子查询静默空结果 / ALTER DROP 索引残留 / UNIQUE INDEX 存量校验 / SELECT * 别名投影 / WAL BEGIN/ROLLBACK 事务边界 / aria $in 与级联重复扫描性能 / $and 等值下推 / ANALYZE 索引统计 / React-Vue hooks 生命周期 / 迁移主键兜底 + 58 回归	2026-08-14 22:53:46 +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	cbe407eb49	fix: v0.7.1 API 修复与防御统一 — static create / 未 open 防护 / 原型污染 / lint 清零 ... - MetonaSqlark.create 静态工厂（README 示例在 ESM/Node 下此前 TypeError）， 独立 create 函数委托静态实现 - close 未初始化防御（engine undefined 不再崩溃） - AriaEngine hasTable/getTableNames/getTableSchema 统一 ensureOpen - 事务回滚失败不掩盖原始错误 - __proto__ 列名防护：Executor 列映射 Object.create(null) + schema 校验拒绝 - lint 清零（移除 5 处未使用导入） 测试 1147 → 1155（73 套件）；行覆盖率 89.8%；版本 0.7.1	2026-08-13 11:14:42 +08:00
thzxx	57415975ea	feat: v0.7.0 参数化查询 + 事务增量 flush + 复合主键语义硬化 + EXPLAIN 真实索引信息 ... - 参数化查询 db.query(sql, params)：词法层 ? 绑定 + SQL 字面量安全编码 （'' 转义/注入防护）；参数计数不匹配 PARAM_ERROR；对象参数显式拒绝 - KVStoreEngine 事务增量 flush：行级变更追踪，commit 仅写改动行 （1000 行表改 1 行：日志 1 条目 vs 整表 1000 条目）；级联影响表漏写修复 （txFullTables 同步加入 txDirtyTables）；移除每次 commit 全量 checkpoint （阈值自动 checkpoint + close 统一截断） - 复合主键显式拒绝：createSchema 校验期 SCHEMA_ERROR + ALTER ADD 主键列防护 （此前静默取第一个主键，其余标记失效） - EXPLAIN usingIndex 真实命中信息：pk / index:col / none 测试 1126 → 1147（72 套件）；行覆盖率 89.8%；版本 0.7.0	2026-08-13 10:57:26 +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	ef1934a38c	fix(P0): v0.6.2 数据正确性专项 — 深度审计 6 项修复 + 22 回归 ... - KVStoreEngine 数值主键 update 丢行（P0）：String 化主键回查不命中 → 误删 KV 行 （重启丢数据）；改为单次全表扫描 + 受影响集合过滤（兼消 O(N×M) 回查开销） - update 主键撞已有主键静默覆盖（P0，Memory/Aria）：抛 DUPLICATE_KEY，事务路径同拦截 - Aria 二级索引范围查询边界算法错误（P1）：Number(v)±1 构造 key 漏小数/字符串数据； 改全索引扫描 + matchWhere 过滤，边界语义统一 - Aria 索引列 IS NULL 返回空（P1）：null 等值/含 null 的 IN 不走索引（回退全表） - AriaEngine unique 约束未强制（P1）：insert 整批预检（批内互查+索引扫描，失败整批 不落库）+ update 排除自身旧条目检查；新增 LSM.prefetchPrefixRanges 批量预加载 - 非主键 update 索引旧值残留：统一传旧行清理（消除唯一性误报与索引膨胀） - EXPLAIN 写语句产生真实副作用（P2）：仅 SELECT 执行，UPDATE/DELETE 用 count 估算 测试 1092 → 1114（70 套件）；行覆盖率 89.6%；版本 0.6.2	2026-08-13 09:51:26 +08:00
thzxx	0e192e0d84	docs: 重写 README 与 site 站点 — 剥离历史版本注释、统一信息架构（核心特性/快速开始/API速览/引擎对比/AriaEngine 专章/项目状态）；更新 docs.html 存储模式对比表（移除 IndexedDB 遗留列）+ v0.6.1 修复记录；同步测试数 1093/70 套件/89.7%；修正 VERSION 常量 0.6.0→0.6.1 并重建 dist	2026-08-10 21:50:49 +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	8a78f27f7d	fix: v0.6.1 生产可用性深度审查 — MemoryEngine 级联环无限递归（P0）/ KVStore 多表事务与级联原子化 / 未open防护统一 / 27 个异常场景测试 + aria级联回归	2026-08-10 14:29:40 +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	cff98b0903	release: v0.4.4 — SSTable 编码修复（UTF-8 字节估算 + u32 长度字段 + v1/v2 双格式兼容），大内容不再崩溃	2026-08-09 21:34:28 +08:00
thzxx	d269bdfb75	release: v0.4.3 — 关闭时序与后台任务加固（close 排空、失败不吞错、compaction 竞态修复）+ 提交先 WAL	2026-08-09 19:48:06 +08:00
thzxx	22b0b1fad4	release: v0.4.2 — 生产就绪与崩溃自愈 + 问题清单修复 + 版本迭代	2026-08-09 19:15:37 +08:00
thzxx	a1e4f5071c	release: v0.4.1 — Aria 级联/ALTER/clearAll + 流式查询/派生表 + 正确性加固 ... 新增： - AriaEngine 外键级联（CASCADE/SET NULL/RESTRICT）+ clearAll() 重置 API - 引擎级 alterTable：Aria DROP COLUMN 重写存储行 + schema 持久化 - 流式查询 queryStream / findStream（LSM 惰性扫描不物化） - FROM 派生表 / 多列 ON 哈希连接 / COUNT(DISTINCT) / NULLS FIRST/LAST - 普通列别名 + ORDER BY 别名 + 无表查询 + 字符串常量列 - 演示页引擎切换器（Memory/Aria）+ 预设自动重置 修复： - Aria WAL DROP_TABLE 崩溃恢复（删表复活）+ 恢复后 WAL 截断 - Memory update/delete 索引维护（unique 约束绕过） - 关联 EXISTS 绑定失效 / HAVING 标量子查询 / INSERT SELECT 位置错位 - 裸布尔列条件（WHERE done / CASE WHEN done） - Aria $in 重复行 / JOIN 主表 WHERE 下推 / DROP INDEX 报错 - ORDER BY/GROUP BY/SELECT 表前缀列 + SQL '' 标准转义 质量：894 测试 · 47 套件 · 81.5% 覆盖率	2026-08-08 13:36:34 +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	eb79b2198e	release: v0.2.5 — 质量加固 + Bug修复 + 性能优化 + SQL扩展	2026-07-29 21:50:53 +08:00
thzxx	3d30e8174d	feat: v0.2.4 OPFS写锁 + 性能基准 + BufferPool集成 + REINDEX/VACUUM + 查询优化器	2026-07-27 22:00:42 +08:00
thzxx	791a5c7415	fix: crypto TS类型修复 + EXPLAIN AST类型补充	2026-07-27 21:58:31 +08:00
thzxx	da999d607b	release: v0.2.4 二级索引 + MVCC + BloomFilter + WAL全同步 + 内存预算	2026-07-27 21:50:15 +08:00
thzxx	2493209611	fix: v0.2.3 OPFS数据恢复 + Aria WAL事务边界修复	2026-07-27 21:30:35 +08:00
thzxx	fef4db44ca	release: v0.2.2 AriaEngine OPFS 自研存储后端 — 零依赖纯文件系统	2026-07-27 21:08:57 +08:00
thzxx	e6efa39d48	release: v0.2.1 生产加固 — WAL CRC/约束激活/Hybrid提交顺序/RESTRICT外键/浏览器兼容表/debug模式/onError回调	2026-07-27 20:47:30 +08:00
thzxx	648526c188	feat: SQL 语法支持 CREATE TABLE IF NOT EXISTS ... - Parser 支持 CREATE TABLE IF NOT EXISTS 语法 - AST CreateTableStatement 新增 ifNotExists 字段 - Executor 表已存在时静默跳过 - 修复 demo.html Aria 预设报错	2026-07-27 17:18:52 +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	1f8e11bf72	feat: SQL 语法支持 BETWEEN AND、DROP TABLE IF EXISTS	2026-07-26 17:55:45 +08:00
thzxx	014e92884c	release: v0.1.14 生产加固 — IDB事务原子性/多标签页感知/幂等init	2026-07-26 17:20:31 +08:00
thzxx	71e238a5cc	test: v0.1.13 新增42项测试覆盖（事务回滚/子查询/外键级联/连接池）	2026-07-26 16:40:11 +08:00
thzxx	0f128da34a	feat: v0.1.13 — 事务回滚 + 子查询 + 外键级联 + 连接池	2026-07-26 16:31:15 +08:00
thzxx	7858cf3720	feat: MetonaSqlark v0.1.12 — 前端TypeScript关系型数据库 ... - 4种存储引擎：Memory / IndexedDB / OPFS / Hybrid - 完整SQL：SELECT/INSERT/UPDATE/DELETE/JOIN/GROUP BY/HAVING/DISTINCT - Query Builder链式API + TypeScript泛型 - 聚合/事务/插件/发布订阅/迁移/导入导出 - React/Vue集成，264测试，93.46%覆盖率，零运行时依赖	2026-07-26 15:18:45 +08:00