tamakyi
496c992e5e
用户报「之前上传的照片找不到了，应该是因为清了应用数据换基线」。查下来与 App 侧无关， 是站点自己两套口径打架： - place_images.dataset_id 带 ON DELETE CASCADE，而读取按 place_key 坐标键、跨数据集。 - 于是删掉旧数据集时图片**行**被级联删了，**文件却留在 media 目录里**。 - 实测（本机）：datasets 只剩 155 号、place_images 0 行、盘上 4 个 .webp 好端端躺着。 同一批附属数据里备注（17）与结论（3+1）因为早就迁到坐标键，毫发无损——只有图片倒霉。 三件事： 1) 恢复：后台首页「图片挂载恢复 → 扫描并恢复」（POST /admin/images/recover， internal/web/image_recovery.go）。只插行、不删文件、不看数据集，按 object_key 判重可反复点。 认地点两处来源：数据集还在就查它的 places；数据集已删就读它留下的 baselines/<id>.sqlite 还原「地点号 → 坐标」。对象键两种历史布局都认（<ds>/<YYYYMM>/<srcPK>-<hash>.webp 与 <ds>/<srcPK>/<hash>.webp）；判据先看文件名有没有 `<数字>-` 前缀，再看中间目录—— 地点号也可能刚好 6 位，只看位数会认错。 2) 防复发：CREATE TABLE place_images 去掉外键 + 幂等 DROP CONSTRAINT；删图接口不再按 dataset_id 过滤（数据集删了也得能删图）；「删除数据集」的二次确认文案改成实话。 3) 报告同类陷阱（未改）：topics 仍带 CASCADE，专题随数据集一起删且没有恢复来源。 测试踩到的坑：图片「按坐标键跨数据集读」+「按 object_key 判重」都不看数据集，用例之间会 互相污染两处——盘上文件（报「应当 2 张、实际 10 张」）与库里的行（Already:1 让兜底分支 根本没跑到，用例差点假绿）。加 isolateImageState（换空 DataDir + 按 place_key 清历史行）， 并给夹具补收尾清理（外键没了必须自己清）。 新增用例 4 条；验收：./scripts/verify.sh 全量 PASS=323 FAIL=0 SKIP=0。
38 lines
908 B
Plaintext
38 lines
908 B
Plaintext
# 构建产物
|
||
/rond
|
||
/rond.exe
|
||
# go build ./... 会按模块名输出到仓库根：漏了这个就会一直当未跟踪文件冒出来
|
||
/rond-with-you.exe
|
||
*.exe~
|
||
/bin
|
||
|
||
# 运行时数据
|
||
/storage/
|
||
/tmp/
|
||
/shots/
|
||
/dist/
|
||
.tmp-test/
|
||
.playwright-cli/
|
||
|
||
# 含密钥的真实配置
|
||
/conf/app.ini
|
||
/conf/app-test.ini
|
||
|
||
# 原始备份
|
||
/data/
|
||
.workbuddy/
|
||
# 但「项目记忆」要跟着仓库走：那批判据与教训是给后续会话看的，不该只留在本机。
|
||
# 其余 .workbuddy 内容（计划、本地设置、临时产物）继续忽略。
|
||
# 注意：只放行 memory 下的 .md——**别写成 `!.workbuddy/memory/**`**，
|
||
# 那会把误落盘的 png/exe 一起放行（本项目真发生过 .test.exe 混进暂存）。
|
||
!.workbuddy/
|
||
.workbuddy/*
|
||
!.workbuddy/memory/
|
||
.workbuddy/memory/*
|
||
!.workbuddy/memory/*.md
|
||
|
||
# 开发期的临时探针/抓取产物（不属于运行时）
|
||
/tmpfog/
|
||
__pycache__/
|
||
*.pyc
|