tamakyi
496c992e5e
图片不再随数据集删除:加「图片挂载恢复」,place_images 摘掉外键
用户报「之前上传的照片找不到了,应该是因为清了应用数据换基线」。查下来与 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。
2026-09-30 19:45:51 +08:00
..
2026-09-19 16:04:00 +08:00
2026-09-30 19:15:48 +08:00
2026-09-30 15:19:42 +08:00
2026-09-20 10:54:51 +08:00
2026-09-24 20:37:57 +08:00
2026-09-19 16:04:00 +08:00
2026-09-30 19:45:51 +08:00
2026-09-18 13:05:49 +08:00
2026-09-18 13:05:49 +08:00
2026-09-18 13:05:49 +08:00
2026-09-24 20:37:57 +08:00
2026-09-18 13:05:49 +08:00
2026-09-19 02:04:03 +08:00
2026-09-18 13:05:49 +08:00
2026-09-18 13:05:49 +08:00