5 Commits

Include renames

Author	SHA1	Message	Date
xuyue	d25b5dbe6d	update	2026-09-27 19:36:28 +08:00
xuyueandClaude Opus 5	ed56a209ea	chore(格式): Prettier 统一到全仓，后端和契约一次性格式化 ... 原来只有 `apps/web` 在 Prettier 下（配置在 `apps/web/.prettierrc.toml`、脚本在 web 的 package.json），后端和契约从来没格式化过 —— 手写在 100 列上下，`db/schema.ts` 还是 drizzle-kit pull 留下的 tab 缩进。两套口径分叉久了，跨端改一处就得记着「这边 什么风格」。 - 配置搬到根目录 `.prettierrc.toml`，内容不变（`semi=false`，其余全默认， printWidth 80 —— 和前端已有的格式一致，不另立一套宽度）； - 脚本统一成根目录 `bun run fmt`，覆盖 `apps/*/src`、`apps/web/tests` 和两个构建 配置；web 自己那份 `fmt` 和重复的 prettier 依赖删掉； - `.prettierignore` 挡掉两类不该碰的：drizzle-kit 生成的 `src/db/meta/` 结构快照 （它是 db:generate 的比对输入，只该由 drizzle-kit 写）、unplugin 每次 dev 都会 重写的 `auto-imports.d.ts` / `components.d.ts`； - 全量跑了一遍。纯格式，无行为改动：api typecheck / check:routes / check:ast、 前端 type-check 全过，起 api 打了接口确认正常。前端这 39 个文件的小改动是 prettier 版本漂移（类型断言的换行口径变了），不是新配置带来的。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-16 08:27:34 -06:00
xuyueandClaude Opus 5	bb4b5825c3	feat(迁移): 0000 改成可执行，空库能自举 ... 0000_crazy_gateway.sql 原本是 drizzle-kit pull 的产物，整份被 /* */ 包着、 可执行语句 0 条，所以任何新库的结构都只能先手工 psql 灌一遍 schema.sql 再打基线。 现在它的内容由 docs/specs/schema.sql（2026-08-07 的生产 pg_dump --schema-only） 机械转换而来：去掉 psql 专有指令 12 条、去掉 7 张 Django 遗留表及其索引外键 41 条， 保留 212 条语句、顺序不动。转换脚本入库在 docs/spikes/。 不含 Django 那 7 张表，是因为 meta/0000_snapshot.json 从来就没有它们（pull 当时 tablesFilter 滤掉了），不建它们才和快照一致；0002 那串 DROP ... IF EXISTS 在新库上 空转、在生产库上真删，两边跑同一串迁移落点相同。 改 0000 对生产库没有影响：migrator 只比 created_at、从不校验 hash，而生产库那行 baseline-0000-faked 早把它挡在门外了。 migrate.ts 配套：空库直接从 0000 建起（并自建 drizzle 记账表——原来这步由 drizzle 的 migrate() 顺手做掉）；自举时不触发破坏性闸门，因为空库上没有数据可丢，拦下来只会逼 每个新环境都带一次 OJ2_ALLOW_DESTRUCTIVE，把这道闸训练成习惯动作。「有表但没基线」 仍然 exit 3。 验证：空库自举出来的结构，和「灌 schema.sql + 打基线 + 跑迁移」这条老路子跑出来的 结构，pg_dump --schema-only 逐字节一致（734 行，零差异）。 转换时踩到两个坑，都写进注释了：注释里不能出现 statement-breakpoint 的字面量 （readMigrationFiles 纯文本切分，会把注释从中间切开）；过滤 Django 对象要看 public.X 形式的对象引用，不能扫语句字样——user 表有一列叫 auth_token。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 09:54:31 -06:00
xuyueandClaude Opus 5	2e871cb5b0	refactor(迁移): 换掉 drizzle 的执行器，一条迁移一个事务 ... drizzle 的 migrate()（pg-core/dialect.js）把所有待执行的迁移塞进同一个 session.transaction()，两个后果：第 3 条失败会把第 1、2 条一起回滚，和 Django migrate 的逐条提交语义不一样；以及 CREATE INDEX CONCURRENTLY 一律跑不了， 没有任何开关。 现在自己按 journal 逐条执行，一条一个事务。文件第一行写 `-- oj2:no-transaction` 的迁移走裸执行（简单查询协议——扩展协议会把语句包进隐式事务块，CONCURRENTLY 照样被拒），代价是没有回滚，所以这类迁移一个文件只放一条语句。 记账行的写法和 drizzle 完全一致（hash = 整文件 sha256，created_at = journal 的 when），migrator 又只比 created_at、不校验 hash，两套执行器可以互换。 顺带：日志和报错说得出迁移文件名了（readMigrationFiles 不返回 tag，自己读一遍 journal），失败时打印的是 Postgres 那句话而不是 postgres.js 的内部堆栈， 新增退出码 5。 实跑验证（本机 Docker，生产 schema 灌进探针库）：CONCURRENTLY 带标记成功、 indisvalid = t，去掉标记复现 "cannot run inside a transaction block"； 0003 成功 + 0004 失败时，0003 留下、0004 的首条合法语句没留下。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 09:54:01 -06:00
xuyueandClaude Opus 5	586c88f629	build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留 ... 一条线上的三件事：让 drizzle 的迁移机制真正可用 → 用它加索引 → 用它清掉 不再需要的 Django 表，最后接进部署和 CI。 ## 1. 让 drizzle-kit generate 可用 原本以为不能用：只加一个索引，generate 却吐出一堆噪音，其中 5 条 `DROP SEQUENCE auth_*/django_*` 打到生产库上会直接搞坏旧后端。 逐个查下来全是 `pull` 出的基线自己不能 round-trip，都是可修的： - **快照里的 Django 序列**：tablesFilter 只过滤表、不过滤它们的序列。 已从 0000_snapshot.json 清掉。 - **bigint 上限精度**：pull 生成的 `maxValue: 9223372036854775807` 是 JS number 字面量，round-trip 成 ...776000，每次 generate 都多出 10 条 ALTER COLUMN。改成字符串。 - **表达式索引的 opclass**：problem_tag_name_ci_unique 在快照里带 opclass，drizzle 自己序列化不出来，导致每次 drop + recreate。已去掉。 改完 `generate` 是干净的 no-op。 两个改不掉、只能绕的写进了 CLAUDE.md：索引 `.desc()` 生成 SQL 时会被丢 （单列索引不写方向即可，Postgres 用 Index Scan Backward 服务 ORDER BY DESC，实测同样 0.08ms）；migrator 把所有语句包一个事务， CREATE INDEX CONCURRENTLY 跑不了。 最容易吃亏的是 drizzle 没有 --fake-initial：对已有数据的库直接 migrate 会从 0000 跑起、撞表回滚，**而且 exit 1 但一个错误都不打印**。 ## 2. 0001 提交列表索引 `WHERE contest_id IS NULL ORDER BY create_time DESC LIMIT n` 用不上现有的 contest_create_time_idx (contest_id, create_time DESC) —— Postgres 不把 `IS NULL` 当成能吃掉首列、从而继承第二列有序性的等值条件。把 enable_seqscan / enable_bitmapscan 全关掉逼它用也不肯，宁可走单列 contest_id 索引再全量排序。于是每翻一页都 Parallel Seq Scan 扫完整张表。 换成部分索引后谓词由索引自己保证，索引序就是查询要的排序序。生产快照 （12.3 万条提交）实测首页取 10 行：61.8ms / 读 18936 blocks → 0.22ms / 读 34 blocks。端到端 94ms → 6ms。 真正要命的不是单次 61ms，是每个请求都要把 169MB 的表刷一遍 shared_buffers —— 一节课几十个学生同时开提交列表，磁盘和缓存直接被打穿。 ## 3. 0002 删掉 Django 残留 确认旧 Django 后端不再使用、也不再作为回滚路径。删前核实过：没有任何 OJ2 保留的表引用这 7 张，3 条外键全在它们内部（所以不用 CASCADE，真有 漏网的会报错而不是被悄悄级联掉）；5 个序列都由各自的表 owned，随 DROP TABLE 一并消失；数据全是 Django 自身元数据。tablesFilter 随之移除。 **回滚路径就此作废** —— CLAUDE.md 开头和 runbook 的「回滚保证」「七、回滚」 都改了。这条迁移已在本机 dev 库和生产快照副本上跑通，**生产库尚未执行**。 ## 4. migrate 接进部署与 CI deploy.sh 在构建之后、起栈之前跑 `oj2-api migrate`，失败就中止部署（旧 容器原样还在跑）。CI 走的也是 deploy.sh，所以不用给 GitHub 配数据库凭据， 也不用把生产库对外开放。 迁移文件**不内嵌进二进制**，随镜像装在 /usr/local/share/oj2/migrations。 这样 drizzle 的 migrate() 能原样用 —— 靠 _journal.json 自动发现，新增迁移 不用改任何代码，和 Django 扫 migrations/ 是一回事。内嵌就得为每条迁移 手写一行 import，那是迟早会漏的账。（CLAUDE.md 里「单二进制不能读文件」 那条讲的是 node_modules 和 import.meta.dir 推路径，按显式绝对路径读一个 数据目录不在此列。） 三道闸门，都是写完测出来才补上的： - **破坏性迁移拦截**：DROP TABLE / DROP COLUMN / DROP SCHEMA / ALTER COLUMN ... TYPE / TRUNCATE 命中就退出 4，需要 `OJ2_ALLOW_DESTRUCTIVE=1` 显式放行。DROP INDEX / DROP CONSTRAINT 不算， 拦了只会让人习惯性带上放行开关。扫描前先剥注释，避免误报。 - **基线缺失**：退出 3 并直接打印该敲的 SQL。注意判的是 `max(created_at) < 0` 而不是「表不存在」—— 表存在而为空（上次迁移失败 留下的）同样是没基线。 - **迁移目录读不到**：这是最可能犯的错（Dockerfile 漏拷），原本是 drizzle 的堆栈，现在直接说该检查哪一行。 另外发现 0000_crazy_gateway.sql 是 pull 的产物，**整份被 /* */ 包着， 可执行语句 0 条**，所以这个库根本不能靠迁移自举建表。原先写的「空库就从 0000 建」跑起来会炸在一个和真实原因毫不相干的 unterminated /* comment 上。 现在如实说明：结构只能来自 docs/specs/schema.sql 或生产 dump。 验证：镜像内编译（ARTIFACTS=build）出的真实镜像跑完五种场景 —— 拦截、 放行、幂等、无基线、漏拷目录，全部符合预期；dev 形态同样五种场景全过。 tsc / 路由遮蔽 / deploy.sh 语法 / generate no-op 都通过。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 07:56:30 -06:00