|
|
64b264ee73
|
feat: 品牌抓取历史（brand_crawl_logs）+ 品牌页展示
crawl_tasks 每品牌只有一行（uq_crawl_tasks_brand），入队/完成都是覆盖，
答不了「什么时候爬过、爬了几次、哪次没抓到」。故新增 append-only 历史表：
- 在 Report 的同一事务里写一条：品牌 / 任务 / 状态 / 第几次尝试 /
场次上限 / 实际上报场次 / 错误 / 执行者 / 领取与回报时间
- 写入后只保留该品牌最近 30 条（CrawlLogKeepPerBrand），
历史用于排障而非归档，避免无限增长
- 品牌详情页新增「抓取历史」区块（结果 / 明细 / 耗时 / 执行者），
与「更新记录」上下相邻，构成「抓取一次 → 每场入库结果」的完整链路
量级：每品牌每次抓取 1 行、约 200B（含索引）；全站跑一遍 23237 行 ≈ 4.6MB。
|
2026-10-25 11:37:43 +08:00 |
|
|
|
c8a70760cc
|
feat: 入库结果落库 + 品牌详情展示更新记录
背景：任务只有 status=done，分不清「新建」「已存在跳过」「已删除跳过」，
品牌更新历史只能在进程日志里翻，日志一滚就没了。
- ingest_jobs 新增 outcome / note / brand_id（迁移 2026-10-25-01）
outcome 记结果类型，note 记人话细节（新建 N 张图 / 已存在(status=published)）
- 提交任务时解出 brand_id 落库，品牌详情页按 (brand_id, id DESC) 直接查
- 处理时优先用 job.brand_id，payload 里的 hashid 只作老任务兜底：
避免「别的实例盐不同 → 解出错品牌 → 整场 brand not found」再发生
- 品牌编辑页新增「更新记录」区块：时间 / 场次 / 结果 / 明细（含失败原因与尝试次数）
- 测试：fake 仓储补齐新接口，capture 仓储记录 outcome 供断言
|
2026-10-25 11:06:16 +08:00 |
|
|
|
151e09ab30
|
feat: 抓取任务队列 + 媒体机直传 + 向量回填
crawl（品牌抓取任务队列）
- /admin/internal/crawl/tasks 领取 / :id/result 回报，spider 可常驻拉任务
- 后台品牌列表支持「加入抓取队列」，队列页可看状态与重试
- 租约超时的 running 自动回收为 queued，避免 worker 崩溃后任务卡死
media（媒体机直传）
- ingest 载荷新增 main_key/detail_keys/main_size/detail_sizes：
有 key 就直接落库，跳过下载与上传；与 URL 形态可逐图混用
- 细节图按 Details/DetailKeys 两者较长者遍历（只给 key 时不再丢图）
- 媒体机上传的 key 不进失败回滚清单（内容寻址、可能与他人共享）
- /admin/internal/upload-url 签发 S4 PUT 预签名（spider 不持有 AK/SK）
embeddings（向量回填）
- GET /admin/internal/embeddings/pending 派发缺向量的图（含可直接下载的 url）
- POST /admin/internal/embeddings 回写向量并重算近邻；失败项计入
image_embedding_failures，连续失败到上限后退出队列（坏图不占位）
- 近邻重算改为异步串行：同步会让 100 张的批次 POST 超时（实测 >60s）
- 新增 key 分支单测：混用 key/url、细节图只给 key、字节数、回滚清单、向量占位
|
2026-10-25 00:37:13 +08:00 |
|
|
|
1de1ec46a6
|
update
|
2026-10-18 17:42:10 +08:00 |
|
|
|
1b06bd5bda
|
update
|
2026-09-30 11:58:32 +08:00 |
|
|
|
361ffc01af
|
update
|
2026-09-29 19:59:30 +08:00 |
|
|
|
d15d2a4701
|
update
|
2026-09-28 10:52:50 +08:00 |
|
|
|
aaeab41d67
|
update
|
2026-09-25 19:59:06 +08:00 |
|
|
|
42f6316125
|
update
|
2026-09-25 11:31:52 +08:00 |
|
|
|
f04b5707cb
|
fix(publish): 最终审查补修（编辑页删图重算计数、迁移编号后置、图片 id 稳定断言）
D1 编辑页删图：DeleteRunwayImage/DeleteSnapImage 在单事务内取父 id→软删→按存活行重算 image_count，口径与审核侧 SoftDelete*Image 完全一致（走秀只计主图、街拍计全部），并补集成测试（含重复删同一张）
D2 不可逆删表迁移 02→05（git mv），使文件名顺序 01→01b→03→04→05 与必需执行顺序一致；同步 README/文件头/规格/计划全部引用
D3 新增「通过审核后图片行 id 集合完全一致」的集成断言，锁住单表发布头号收益
D4 修正 01 迁移文件头「只做三件事」自相矛盾表述；D5 删除受版本控制的陈旧产物 cmd/dbtool/db_dump.json 并加 gitignore 规则；D6 清理遗留空目录 scripts/tmp_verify/
|
2026-09-23 16:27:14 +08:00 |
|
|
|
be4db0bf96
|
fix(publish): 最终审查修复波——迁移索引口径 / 入库计数 / 仓储证据
C1（关键）：2026-09-22-03 的街拍实体键索引改用最终表达式
(city, year, COALESCE(title, ''))，与体检及 StreetSnapEntityState 口径一致。
此前索引按 (city, year) 比体检更窄，同城同年多专题的合法数据会通过体检、
再由索引抛原生 23505；04 退化为幂等兜底并在注释说明真正常态由 03 承载。
新增 db/migrations/README.md，写清迁移链执行顺序与各步前提/不可逆点。
I1：processRunway 的 image_count 改为按实际落库主图行数（countMainImages），
不再用 len(p.Looks)（空主图 / sha1 重复会被跳过，导致计数偏大且不再自愈）。
补 service 单测与「入库后 image_count == 存活主图行数」的 DB 断言。
I2：三个迁移文件不再把已删除的一次性搬迁脚本写成硬前置，改为写明取回方式
（git show c4bafc5:scripts/migrate_single_table/main.go，并须在旧代码树上运行）。
I3：新增 SetRecordStatus / SetStreetRecordStatus 仓储集成测试：
pending 经仓储通过后在公开视图可见、驳回后不可见、不存在的 id 返回 ErrNotFound。
Minor：修正锁不住口径的走秀 image_count 测试（改为删主图、留细节图）；
修正去重注释与事实不符（含 FindNearDuplicateImage 注释）；
ListRecords / ListStreetRecords 改用 Scope 杜绝 Count 后复用 *gorm.DB；
dbtool 视图改 CREATE OR REPLACE 并重跑 dump（仍 4 视图、无草稿表）；
删除挂在 Popular 上的「IDs 返回…」注释；README 改为单表 + status 现状；
SetRecordStatus 注释写明有意不校验前置状态；规格补两条已知不一致。
|
2026-09-23 16:03:22 +08:00 |
|
|
|
d68a57009c
|
chore(publish): 删除草稿表与草稿模型
|
2026-09-23 13:55:24 +08:00 |
|
|
|
12d05f75e9
|
fix(publish): 迁移03街拍体检同步 city+year+title 口径，补 04 体检与查重口径测试
|
2026-09-23 13:14:48 +08:00 |
|
|
|
ce4f8b786d
|
feat(publish): 街拍实体键细化为 city+year+title，支持同城同年多专题
|
2026-09-23 13:04:37 +08:00 |
|
|
|
474e1c1a64
|
feat(publish): 实体键唯一索引，保证一个实体一行
|
2026-09-23 10:47:37 +08:00 |
|
|
|
83823a8d49
|
feat(publish): 正式表加发布状态与公开只读视图
|
2026-09-23 09:56:35 +08:00 |
|
|
|
d908036621
|
update
|
2026-09-22 11:12:23 +08:00 |
|
