xuyue/OJ2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
280 Commits 1 Branch 0 Tags
954797a9a5c1f5d0c6439091f56c4a4fcf0e8cc3
Commit Graph
16 Commits
Author SHA1 Message Date
xuyueandClaude Opus 5 954797a9a5 feat(AI 提示): 提示分级（L0 反问 / L1 定位 / L2 概念）与输出后过滤
Deploy / deploy (push) Canceled after 0s
Details 
提示不再一上来就把话说完。等级记在「学生 × 题目」上，没有单独的表 —— 它就是
ai_hint.level 的历史，当前等级 = 这道题上（最近一次 AC 之后）给过的最高一级。

阶梯（services/hint-level.ts）
- 只有学生点「再多一点提示」才升级（请求带 more），不带就按当前等级再生成一次
- 升一级要先再交一次：锚点是「这一级是**什么时候**开出来的」，也就是这一级最早那条
  提示的 ai_hint.create_time，必须有比这个时刻更新的提交才准 +1。锚点不能用提示所在
  那条提交的时间 —— 端点谁的提交 id 都认（只校验归属），拿一条老提交去要提示，锚点
  就退回到那条老提交的时间，连点两下 more 就能从 L0 爬到 L2，一次新提交都不用交
- AC 之后清零；编译失败自成一档（level = -1），既不消耗也不推进阶梯
- HINT_MIN_FAILURES 3 → 1：门槛的活由阶梯接走了，第一次失败只开放 L0，而 L0 只反问、
  什么都不泄露，拦着它没有意义
- canEscalate 由后端算好在 done 事件里给，前端不自己推阶梯

输出后过滤（services/hint-filter.ts）
- 「不要给代码」写在 prompt 里只是软约束，模型忍不住一次就把这一级的意义废掉了。
  所以整段生成、过滤通过才推给前端，逐字显示改由前端模拟 —— 边流式边过滤做不到，
  发现违规时内容已经在学生屏幕上了
- 判定只用客观、低误报的信号：代码块、过长的行内代码、整行不含中文的类代码行、
  和标准答案重合 3 行以上、L0 一句问句都没有
- 违规就重生成一次，只重一次，再不过发写死的兜底话术。重试措辞按档分叉：编译档本来
  就允许给片段，对它说「不要出现任何代码」等于用阶梯的标准把这一档也砍了
- 两次都留痕（filter_attempt / filter_blocked / filter_reason），7.5 的输出过滤触发率
  就是从这三列出来的

services/ai.ts 加 streamWhole：事件形状和 streamChat 一样，前端不分叉。produce 期间
每 15 秒发一行 SSE 注释当心跳 —— 这条流中间有一大段静默（诊断 20s + 生成 60s +
重生成 60s，最坏 140 秒），而 NPM / nginx 的 proxy_read_timeout 默认 60 秒，超了学生
看到「请求失败」，后端却还在烧第二次调用，那条提示照样落库、照样把等级推上去。

prompt 版本另开 3 / 4（阶梯上每一级都换了 system），编译档仍走 1 / 2 的单段式基线，
两批数据不混在一起。迁移 0021 给 ai_hint 加四列，都可空、不带默认值，已有的行留 null
表示「分级上线前」。

实跑
- 阶梯：在 dev 库上用真实行驱动 decideHintLevel。正常路径 S1→S2→S3 走出 L0→L1→L2，
  同级连点 more 不升，AC 之后回 L0，编译档给 L-1 且不推进阶梯。把旧锚点规则复刻出来
  跑同一组数据做对照：只拿最老那条提交反复 POST，旧规则 L0→L1→L2（零新提交），
  新规则钉死在 L0，正常路径两者行为一致
- 过滤：起假 AI 服务端走完整条链路。L1 摊平代码→重生成后合规（attempt 2 / 未拦），
  L0 两次都甩代码块→兜底话术（blocked，reason 两条相连），编译档抄标程→命中「和标准
  答案重合 3 行」且追加的是分叉后的措辞
- streamWhole：produce 拖 16.5 秒收到 1 条心跳；同一份流喂给前端 consumeJSONEventStream
  只解析出 delta + done（注释行被静默跳过，前端零改动）；中途 cancel 断开后 produce
  跑完不抛
- api / web typecheck、check:routes、fmt 全过

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-09-21 19:03:21 -06:00
xuyueandClaude Opus 5 8b4d8899f9 feat(判题机): 自建镜像升级工具链，语言收敛到 C / C++ / Python
Deploy / deploy (push) Canceled after 0s
Details 
上游 QingdaoU/JudgeServer 停更在 2024-04（registry 上的 latest 和 1.6.1 是同一份
镜像，编译器停在 gcc-13），没有新版可拉，所以自己重编。docker/judge/ 是只改工具链
的 Dockerfile 分叉，server/ 和 Judger/ 从上游固定 commit b28aa56 拉，一行没动。

镜像 oj2-judge-2（不在任何 registry 上：本机 build.sh --save → scp → docker load）
- gcc/g++ 13 → 14.2，Python 3.12 → 3.13.5，都是 trixie 默认
- Go / JDK / Node 整套删掉：前端的题目语言复选框从来只给 C / C++ / Python / SQL，
  12 万条提交里 Java 44 条、Golang 15、JavaScript 3，全是很早以前的
- 体积 1.1GB → 433MB；默认走清华源，构建 12 分钟 → 40 秒（--no-mirror 换回官方）
- deploy.sh 加一道自检：镜像不在本机就中止，并打印该跑的三条命令

C 的编译参数加三个 -Wno-error（implicit-function-declaration / int-conversion /
incompatible-pointer-types）：gcc-14 把它们从 warning 提成了 error，而 -w 压不住。

语言值统一成 Python（迁移 0019 / 0020）
- 0019：Python3（104527 条提交）与 Python2（3 条）并成 Python，一并改掉 937 道题的
  languages、75 个 template 键、15 个 ast_rules 键、257 条 answers、1235 个用户的
  成就指标 _languages（languages_used 重算，总和 1928 → 1925，少的 3 个是同时用过
  两种 Python 的人）
- 0020：把 Java / JavaScript / Golang 从 84 道题的可选语言里摘掉 —— 不摘的话那些题
  的语言下拉还能选 Java，提交必 SYSTEM_ERROR
- 契约新增 normalizeLanguage() 别名表，判题侧一律走 judgeConfigFor()：旧客户端
  localStorage 里的 Python3、迁移前排进队列的任务都还能判；协作的语言归一也走它，
  否则上线那一刻学生页面里的 Python3 会静默落到 C
- 回滚要连数据一起回，只滚代码会让所有 Python 提交变 SYSTEM_ERROR

实跑
- 判题冒烟 docker/judge/smoke.ts 13 条全过：三种语言、六种状态码、gcc 宽松度
- 拿备份里的真实代码逐文件比对新旧镜像的编译结果，0 差异：C 提交 1951 份
  （1725 过 / 226 CE）、C++ 882 份、Python 2000 份、20 篇 C 教程的 93 个代码块。
  不加那三个 -Wno-error 的话，C 有 26 份会从能过变成 CE
- 迁移在灌了 12.4 万行真实数据的一次性库里跑过：0 残留、没有题目被清空；
  dev 库用真正的执行器跑通
- check:ast 56 个 target 全过，前后端 typecheck 均 0

顺带记下一个升级之前就有的坑（现在随 Go 一起消失，写在 README 里）：GOCACHE 指向
容器的 tmpfs，判题机重启后第一次 Go 提交是冷构建，Go 1.22 要 5.6 秒 CPU、超过 3 秒
的编译预算，于是重启后第一个交 Go 的学生必吃一次 CE，后面的人缓存热了又都正常。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-20 06:24:05 -06:00
xuyueandClaude Opus 5 06ad6745b7 feat(AI 提示): 两段式提示——先诊断出错误标签，再生成提示
Deploy / deploy (push) Has been cancelled
Details 
AI 时代 OJ 设计的 2b。标准答案能让提示准得多，但不能进生成提示的 prompt
（学生代码里一段注释就能把它套走），所以拆成两段：
- 诊断：看得到标准答案、第一个没过的测试点、带行号的学生代码；出参只允许
  { tag, lines, confidence }，safeParse 过闸、多余字段剥掉，没有自由文本通道
- 生成提示：看不到标准答案和测试点原文，只多一句「问题定位：X，大约在第 a 行」
- 诊断失败（20 秒超时、不是 JSON、校验不过）退回单段式；同一条提交复用诊断；
  编译失败不诊断
- 契约新增 HINT_ERROR_TAGS（13 个，落库值，只增不改）与 hintDiagnosisSchema
- 迁移 0018：ai_hint 加 diagnosis / diagnosis_error 两列
- 单段式 prompt 原样搬进 services/hint-diagnosis.ts，记版本 1；两段式记版本 2
- completeChat 支持 JSON 模式和自定义超时，现有调用不受影响
- 开关 AI_HINT_DIAGNOSE 默认关（2a 的基线还在攒），两套生产 compose 透传

实跑（一次性库 + 本地假 LLM）：开关关时请求与 2a 逐字节相同；开时正常 /
复用 / 坏 JSON / 非法标签 / 行号越界 / 超时 / 编译失败七种场景符合预期；
12 次模型请求里诊断全都带标准答案和测试点，生成全都不带。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-19 06:56:38 -06:00
xuyueandClaude Opus 5 47d8f46bdb feat(AI 提示): 提示落库并收集学生评价，落进 ai_hint
Deploy / deploy (push) Has been cancelled
Details 
AI 时代 OJ 设计的 2a：先把现有提示记下来，为后面的分级和两段式诊断攒对照数据。
提示本身的行为不变，发给模型的 prompt 一字未改。
- 迁移 0017 建 ai_hint：模型、prompt 版本、内容、错误、耗时、学生评价；
  成功和失败都记（失败率是 AI 悄悄变差时最先动的数）。挂在 submission 上 CASCADE
- streamChat 第三个参数改成 { onComplete, onError }：onComplete 的返回值并进
  done 事件，提示 id 由此带回前端；班级学情分析那处调用同步改写，行为不变
- 落库失败只记日志，不影响学生拿到提示
- 新增 POST /ai/hint/:id/feedback：只能评自己的提示（别人的一律 404），可以改票
- 前端提示生成完出「有帮助 / 没帮助」，选中的高亮；后端没存上时不出按钮
- 实跑：本地假 LLM 验证成功 / provider 断开 / 缺 AI_KEY 三条路径的落库，
  评价接口六种请求，浏览器里按钮出现、改票、重复点不发请求

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-19 06:00:10 -06:00
xuyueandClaude Opus 5 a0ef204bd2 feat(提交): 采集编辑过程信号，落进 submission_trace
Deploy / deploy (push) Has been cancelled
Details 
AI 时代 OJ 设计的第 1 步：给「可信 AC」和学情分析攒数据，本身不判任何事。
- 契约：提交请求加可选的 trace（活跃时长、键入/粘贴/删除字符数、切后台次数等，
  只有计数、不含按键内容）；写成 .optional().catch(undefined)，坏了就当没带，
  不让附带数据把提交挡成 400
- 迁移 0016 建 submission_trace，与 submission 一对一、CASCADE；since_prev_ms
  由服务端在同一条 INSERT 里算（排掉自身），bigint —— 实测已有 44 天的间隔，int4 装不下
- 后端写 trace 失败只记日志，不影响提交
- 前端 oj/problem/utils/editTrace.ts 是模块单例（扩展对象不能过 Pinia 的响应式代理），
  只数带 userEvent 的事务：格式化回写 / 载入草稿 / 协作对方的改动天然排除；
  closeBrackets 越过右括号时是原样替换，按 no-op 跳过。比赛编辑器同样挂上
- 实跑：后端四种请求、前端浏览器里键入/粘贴/删除/setCode 回写/切后台/提交后清零，
  计数与预期逐项一致

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-19 05:46:55 -06:00
xuyueandClaude Opus 5 6e63866cc9 perf(提交列表): 按用户名、题号筛选走索引，不再扫全表
Deploy / deploy (push) Has been cancelled
Details 
用户名筛选：user_id 先查成字面列表，不再把子查询夹在 OR 里（那样整条 OR 不可索引），
加 trigram 索引接住 ilike '%x%'；翻页先圈出匹配行再排序取页，避开规划器顺着时间索引
倒扫、边扫边滤的计划。快照上查一个班 70~107ms → 5~14ms；匹配 9.5 万条的年级前缀
从 34ms 变成 70~90ms，实际不这么查。

题号筛选：先解析成 problem.id，加 (problem_id, create_time, id) 部分索引。老题和
不存在的题号不再倒扫大半张表（34~67ms → 4ms），题号筛选也能走游标深翻页，
count 不再 join problem。

迁移 0015 装 pg_trgm（官方镜像自带 contrib，trusted 扩展）。39 个筛选组合的响应
与改动前逐字节一致。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xg91q3JsunDE7EYoi9G3i2
 2026-09-13 23:47:24 -06:00
xuyue a475cac128 fix(数据库): 生产库里还留着一张空的 django_migrations，补一条迁移删掉
Deploy / deploy (push) Has been cancelled
Details 
0002_drop_django_leftovers 声称删掉了旧 Django 的 7 张框架表，但生产库实测有 29 张
public 表 = schema.ts 的 28 张 + 一张 0 行的 django_migrations：另外 6 张
（auth_group* / auth_permission / django_content_type / django_dramatiq_task /
django_session）确实都不在了，只有它残留下来。原因已无法从库里复原——0002 的记账行
在，说明当年执行过，而 DROP TABLE IF EXISTS 不会静默跳过它后面的语句。

全仓（二进制、路由、compose、脚本）零处读写这张表，表里 0 行，所以直接删掉。
用 IF EXISTS 让两条既有路径收敛到同一结构：空库自举时 0002 已经删过它（空转），
老生产库还留着（真正动手）。实测两条路径出来的 pg_dump --schema-only 逐字节一致。

「旧栈起不来」这个结论不变——它缺的是 django_session 等表，不是这一张。

迁移会被破坏性迁移闸拦下，这是有意的，放行方式记进了 CLAUDE.md。
 2026-09-10 04:02:33 -06:00
xuyueandClaude Opus 5 80f3b21e95 perf(索引): 0012 删 21 个冗余索引，0013 加 4 个筛选/聚合索引 
0012 —— 删的都是 Django 建的，列是某个复合索引的最左前缀，规划器本来就走那一个，
多出来的只是每次写入多维护一棵树：17 个前缀被覆盖的、3 个 _like（text_pattern_ops）
副本、1 个同表同列的完全重复（problemset_submission.user_id 上有两个）。
索引 107 → 86 个，32MB → 29MB。

删之前逐条确认过复合索引的第一列就是被删索引的那一列，删之后 19 条代表性查询的
执行计划逐条对过，没有一条退化成 Seq Scan，只是换了覆盖它的那个索引；级联删除会
用到的外键检查路径也都还有索引可走。

0013 —— 拿 auto_explain 把 60 多个读接口打一遍抓出来的真实慢查询，候选索引一个个
建出来实测：

- submission (language, create_time) WHERE contest_id IS NULL — 3.2MB
  语言筛选原来一个索引都没有，count 固定 75~82ms / 18448 buffers，筛什么值都一样。
  改后 Python3（占 8 成）80 → 11ms、C 77 → 1.6ms、SQL 82 → 0.06ms。更要命的是冷门
  语言翻页：Python2 只有 3 条全是 2022 年的，分页索引得从最新倒扫到底，43ms 全表扫
  → 0.02ms
- submission (result, create_time) WHERE contest_id IS NULL — 3.2MB
  count result=-1 75 → 2.0ms、result=-2 36 → 1.0ms
- submission (user_id, problem_id, result, create_time) WHERE contest_id IS NULL — 4.2MB
  覆盖索引，给「在全部公开提交上做聚合」那几个接口。它们慢的不是聚合本身，是为了读
  这四个小列把 145MB 的堆翻一遍（code 和 info 占了这张表绝大部分体积，聚合一列都用
  不上）。走 Index Only Scan 只读 6MB：教师统计全站 186 → 49ms（消掉 4.2MB 落盘
  排序）、活跃榜 108 → 18ms、AC 趋势 120 → 41ms
- flowchart_submission (create_time) — 64kB
  列表分页从 hash join 全表再 top-N 排序（4.5ms / 551 buffers）变成 0.19ms / 47

全列 ASC NULLS LAST 靠反向扫，理由同 submission_public_create_time_id_idx 那段注释。
动手前把三种写法在库上对了一遍：两列 ASC 和 create_time DESC NULLS FIRST 一样快，
写成 DESC NULLS LAST 规划器直接不认这条索引、回落到分页索引带 Filter，注释没说错。

回归检查：不带筛选的列表和深翻页仍然走 submission_public_create_time_id_idx，没被
新索引抢走。submission_result_37e2f67a 留着并补了注释 —— 它看着像被新的部分索引
覆盖了，但那条带 WHERE contest_id IS NULL，管不了全库含比赛按 result 统计（实测删掉
之后 count(*) where result in (6,7) 从走索引掉回 75ms 全表扫）。

两条迁移都在生产结构副本和本机 dev 库各跑过一遍。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd
 2026-09-08 18:29:53 -06:00
xuyueandClaude Opus 5 57bc652629 perf(数据库): user 表补两个索引，班级过滤和活跃人数统计不再全表扫 
`user` 原来只有主键和 username 唯一约束两个索引 —— 它是 drizzle-kit pull 从
Django 建的表拉出来的，Django 那边也没建过别的。于是两条常走的查询都是全表扫：

- `problems/:id/beat-count` 里「近两年登录过的活跃人数」按 is_disabled + last_login
  过滤，每打开一次题目详情算一遍；
- `routes/classroom.ts` 的 loadClassUsers 按 class_name（或年级前缀 like '241%'）
  取学生，班级榜、班级对比、AI 学情的排名 scope 都走它。

两千行的表现在扫起来确实不贵，但这是随人数线性涨的那类成本，而且比在应用层加缓存
更根本：不引入陈旧，也不需要考虑失效。

`user_active_idx` 的列序是 (is_disabled, last_login)：等值条件在前、范围条件在后。

迁移只有两条 CREATE INDEX，无附带改动；本机 db:migrate 跑过，两个索引都在。
索引效果没法在本机验 —— dev 库只有 12 条提交、几十个用户，规划器无论如何都走
seq scan，要到生产（12 万提交）才看得出来。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XvmqDsZNyUo9P3sFQtoWVB
 2026-09-07 07:42:46 -06:00
xuyueandClaude Opus 5 2c4d56b29a refactor(后端): 清掉 Django 遗留的死列与手工级联，角色字符串收成一份 
三条迁移，一次部署（0008/0009 含 DROP COLUMN，需要 OJ2_ALLOW_DESTRUCTIVE=1）：

- 0008 删 IP 相关：比赛 IP 白名单（前端本来就没有输入框，detail.vue 无条件置空）、
  submission.ip（前端从未显示过）、以及一次都没被调用过的 IP 限流桶。
  judge_server.ip 是运维数据，保留。
- 0009 删九个只有 Django 时代写过、OJ2 一次都没读过的列：user 的 auth_token /
  open_api / open_api_appkey / session_keys，user_profile 的 blog / github /
  school / major / language。open_api 后台连开关都没有，那段「已经开着就不重置
  appkey」的逻辑从上线起没进过 if。判据是「全仓零读取」而不是「看着没用」——
  raw_password 同样刺眼却是在用的，别一起清掉。
- 0010 给 17 条外键补上删除动作，不再是 Django 留下的一律 NO ACTION。父行消失后
  必然无意义、且不构成学生留痕的走 CASCADE（中间表、题单/教程/成就的组成部分、
  user_profile 与 user_stat）；需要人看见的继续拦着——submission.problem_id、
  以及 user 的绝大多数外键，删用户撞外键会被 handler 翻译成「请改为禁用账号」，
  这是有意的：全 CASCADE 会静默抹掉成就与进度，而 submission.user_id 压根没有
  外键，结果是一半删一半留。六处手工级联随之删掉。

角色字符串收进 packages/contract/src/roles.ts：原先 ADMIN_ROLES / TEACHER_ROLES
在两个文件各抄一份、学生口径在四个文件各写一遍、前端 USER_TYPE 是第三份副本。
AuthUser.adminType 与 drizzle 的列都收窄成联合类型，二十多处 `=== "Super Admin"`
从此受编译器管着（$type 是纯 TS 层的，generate 确认不产生任何 SQL 变更）。

顺带删掉 db/relations.ts —— drizzle-kit pull 的产物，全仓零引用。

一处行为变化：后台用户列表传非法的 ?type= 回 400，不再静默返回空列表；界面上的
下拉只有合法值，打不到这条。

验证：tsc / vue-tsc / vite build / check:routes 全过；三条迁移在 dev 库执行，
并逐条建 fixture 走 HTTP 接口验过删除连坐与拦截（题单五张子表连坐、user_badge
二级连坐、删有提交的题目仍 409、删有表情的用户仍 409）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AeJoYc2t2d7cThVqMBYrBF
 2026-09-02 22:57:45 -06:00
xuyueandClaude Opus 5 e624c62502 feat(提交): 列表标出来自题单的提交
Deploy / deploy (push) Has been cancelled
Details 
submission 新增 problemset_id，学生从 /problemset/:id/problem/:pid 入口提交时
前端带上、后端落库，提交列表在题目后面挂一个「题单 xxx」的标签，点了进题单。

只是来源标记：题单进度和奖章仍由判完之后的 recordSolvedProblem 按「已加入且含
这道题的所有题单」记账，和从哪个入口进来无关，所以这个字段带错顶多标签不准，
不影响成绩。校验只确认这道题在那个题单里 —— 不查 visible / status、也不查有没有
加入，藏起来的题单里还困着已加入的学生；对不上就当没带，提交照收。

外键 ON DELETE SET NULL：删题单不该带走提交，清掉标记就行。索引建成部分索引
（WHERE problemset_id IS NOT NULL），绝大多数提交不来自题单，全列索引是给 12 万行
白建一遍；谓词能被 problemset_id = $1 蕴含，删题单时的外键检查也用得上它。

列表按页单独查一次题单标题，没有把 problemset join 进那条调过的深翻页查询。
比赛提交恒为 null：题单只收非比赛题。

历史回填从 problemset_submission 取「当年首次 AC 那条」，其余老提交无从判断入口，
一律留空。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y7AsqceaUfC81k7UCDcSk2
 2026-09-02 22:06:29 -06:00
xuyueandClaude Opus 5 cf1eea0810 fix(比赛): 学生管理员开卷、导出只剩十行、排行榜翻页错位等四处
Deploy / deploy (push) Has been cancelled
Details 
## 学生管理员在比赛进行中能看所有人的代码

canViewSubmission 里 isAdminRole(user) 是无条件放行的捷径，而 ADMIN_ROLES 含
Student Admin —— 同时 contest.ts 的排行榜又把这个角色算作参赛者。既在榜上、
又能读别人的提交，就是开卷。比赛未结束（未开始 + 进行中）时不再吃这条捷径。

旧后端这里写的是 `not user.is_regular_user()`，学生管理员同样放行，所以这条是
相对旧栈**收紧**的一处，不是修回归。只掐角色捷径，不掐 problem.createdById ——
那是这道题的作者本人，他早就知道答案，挡他没有意义。老师和超管不受影响，他们不参赛。

实跑（造了一场进行中、一场已结束的比赛，各一条别人的提交）：学生管理员在进行中的
比赛里列表 showLink=false、详情 404，比赛结束后恢复 200；超管两种状态都是 200；
学生管理员读**自己**比赛中的提交仍然 200，没有把他自己的记录一起挡掉。

同族的 flowchart.ts canView 有同样的角色捷径，但流程图提交入库时从不写 contest_id
（永远是 null），那条路上不存在「比赛中的别人的提交」，不用跟着改。

## 获奖名单导出，参赛超过 250 人时只导出十个人

rank.vue 用 `limit: total.value || 10000` 想一次拉全量，但 queryInteger 对超出
上限的值是**静默回落到默认的 10**，不是截断到 250。于是 300 人的比赛导出 10 行，
而一二三等奖的分档仍按真实总人数算 —— 老师拿到一份十个人、等级全错的名单，还不报错。
改成按 250 一页循环拉，两个出口都留：拿不满一页说明到底了，比对 total 是防着最后
一页正好整除。班级赛（≤250）碰不到这个坑，全校赛会。

实跑：造 20 条排名，limit=300 后端确实只返回 10 行，limit=250 返回 20，
新逻辑拉回 20。

## 排行榜翻页没有全序

只按 acceptedNumber desc, totalTime asc 排，同分同罚时行序不稳定，而这条列表是
limit/offset 翻页的 —— 同一个人可能在第 2 页出现两次，另一个人从此消失。末尾补
asc(id) 兜全序，id 不参与名次，只保证同分的人每次按同一顺序排。

实跑：20 个同 AC 数同罚时的选手，每页 5 条翻 4 页，共 20 行去重后仍是 20 人，
连翻两轮顺序完全一致。

## acm-helper 两个接口对 visible 的口径不一致

GET 要求 visible = true，PUT 不要求。比赛结束后收起来，核查页就打不开了，
而标记接口还能用。赛后核查恰恰常发生在比赛已经收起来之后，按 PUT 的口径放开。

## 删掉 contest_announcement

旧 Django 栈有「比赛公告」，OJ2 从头到尾没搬：没有路由、没有契约、没有前端页面，
表建在那里纯粹是 introspect 0000 时一起拉进来的。确认不需要，连表带 schema 定义
一起删。

删除前核实：没有任何表外键指向它，序列由本表 owned 会随 DROP TABLE 一并消失，
生产快照（db_backup_2026_08_07）里只有 1 行 —— 2022 年 4 月挂在 contest 1 上的
一条测试公告。迁移不写 CASCADE，同 0002：真有别的东西引用了，宁可报错也别被悄悄
级联掉。

**上生产要显式放行**：migrate.ts 的破坏性闸会拦下 DROP TABLE，得
`OJ2_ALLOW_DESTRUCTIVE=1 docker/deploy.sh`，并按它说的先备份。本机已实跑：
不带环境变量确实被拦，带上之后表和序列都没了，重跑是「没有待执行的迁移」，
db:generate 报 No schema changes（snapshot 与 schema.ts 对齐，不给下一条迁移留假 diff）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013rpSKCNpVcMhTFhw21YiL7
 2026-09-02 20:38:04 -06:00
xuyueandClaude Opus 5 bd84599174 feat(自学): 教程和练一练都留痕，老师能看到谁学了多少
Deploy / deploy (push) Has been cancelled
Details 
自学模块以前一个字节都不落库：读到第几课只存在浏览器的 localStorage 里，
练一练的对错是组件内的一个 ref，刷新即失忆。老师能看到的只有「谁交了题」。

现在两张新表：
* tutorial_progress —— 一个学生 × 一课，记打开次数和累计停留秒数
* exercise_attempt  —— 一个学生 × 一道练习，记试了几次、错了几次、
  第几次做对的、最后一次做错时填的什么

都存聚合不存流水。练习那张表尤其明显：流水会随着学生反复点提交无限长，
而多出来的行回答不了任何新问题 ——「他第 3 次和第 5 次都选了 B」对老师
没有意义，「他试了 7 次才对」有。

停留时长只在页面可见、且十分钟内有过操作时才计。机房的电脑经常开着页面
就走了，不设这道闸的话「停留时长」会变成「电脑开机时长」，老师看到的
数字全是假的。换课、切标签页、关窗口都会先把攒着的秒数冲给**离开的那一课**。

练一练的对错仍然是前端判的：答案本来就随题面一起下发到浏览器，后端再判
一遍也挡不住任何人，只是重复实现七套判题。所以这是教学观察数据，不是成绩。
`last_wrong_answer` 存的是前端拼好的一句人话（「选了 C」「顺序 3-1-2」），
不是原始作答结构 —— 七种题型形状各不相同，存结构就得在后台按题型各写一套
渲染，而老师要看的只是他错在哪。

顺带修掉预测输出题的一个老问题：它的 `submitted` 一旦为真就不再收回，而
`allCorrect` 是跟着输入实时算的，于是学生错一次之后把答案改对，界面直接
跳成「输出正确！」、提交按钮同时禁用，submit() 再也执行不到 —— 这道题
**永远不会被记成做对**。排序/连线/找错/分组四种题本来就在交互处把 submitted
置回 false，只有这里漏了，按同一套补上。

学生端：目录每课显示「✓ 已读 · 11 分钟」和「练一练 3/5」。教程保持免登录
可读，未登录只是不留痕，并明说一句。

老师端：后台新开「自学情况」（教师及以上可进），三个 tab ——
按学生（默认把读得最少的排在最前，这张表要回答的是谁还没开始）、
按练习（每道题的正确率、一次做对几人、做对的人平均试几次；展开看逐人明细
和他们最后错在哪）、按课程。班级框填 3-4 位是具体班级，1-2 位当年级前缀。

外键用了库级 CASCADE，和 Django 建的那批 NO ACTION 不同：删教程、删用户
不必再记得回来手工清子表。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GW5ef6C2kRW8Ru27ghCaUu
 2026-09-01 08:54:27 -06:00
xuyueandClaude Opus 5 6c2381ad2c perf(提交列表): 越早的页越慢，最后一页要等 1.2 秒
Deploy / deploy (push) Has been cancelled
Details 
翻页用的是 LIMIT n OFFSET m，而 Postgres 对 OFFSET 没有捷径：前 m 行必须真的
产出再丢掉，丢弃又发生在 join 之后，每一行都白回了一次表。生产快照（10.4 万条
公开提交）实测最后一页 1258ms、碰了 95347 个 buffer。最早那几页平时没人翻，
数据页从来不在缓存里，全是冷读，所以感受上比新的几页慢得多。

改成两步：先只 select create_time / id 数到第 m 行拿游标——这两列正好是部分索引
的全部内容，跳过 m 行走 Index Only Scan，Heap Fetches 为 0，纯在索引页里数数；
再拿这一行做 keyset 回查，只回表取 limit 行。同一页降到约 9ms、885 个 buffer，
端到端 HTTP 10.7ms。代价变成 O(m) 个索引条目而不是堆页，按快照密度外推，
涨到 100 万条时最深一页仍在几十毫秒量级。

接口签名和前端都没动，页码跳转照旧。offset 为 0、以及按题号筛选时（条件在
problem 表上，第一步得跟着 join，index-only 就没了）退回普通 offset。

部分索引从 (create_time) 换成 (create_time, id)：create_time 由
new Date().toISOString() 生成，只有毫秒精度，不是全序，游标用 <= 回查时同毫秒的
上一页末行会重复出现在下一页页首。加 id 之后两步走同一个顺序。索引 2.3MB → 6.9MB。

索引两列都建成默认 ASC，靠 Index Only Scan Backward 反着扫。别照着 ORDER BY
写成 (create_time DESC, id DESC)：ORDER BY 的 DESC 默认 NULLS FIRST，索引的 DESC
默认 NULLS LAST，规划器认为出不了序，会退化成 external merge sort（5.2MB 落盘），
比不加索引还糟。这一条已写进 schema.ts 和迁移文件的注释。

正确性：在快照上把新旧写法返回的 id 序列逐页比对，14 个 offset × 4 个 limit
共 56 组全部一致，含末尾残页与越界。

比赛提交列表暂不改：单场比赛撑死几千条，offset 不构成问题。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 11:13:38 -06:00
xuyueandClaude Opus 5 586c88f629 build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留
Deploy / deploy (push) Has been cancelled
Details 
一条线上的三件事：让 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
xuyueandClaude Opus 5 f635737453 feat(阶段1): drizzle schema 从本地库生成并剪掉 Django 框架表 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-06 20:45:51 -06:00