 chengma
|
546d9ef7e2
|
fix: 允许已采集 PDD 商品重新采集 (#121)
|
2026-08-10 19:38:40 +08:00 |
|
|
chengma
|
188725ff64
|
feat: 支持批量导入 PDD 商品链接 (#104)
|
2026-08-10 16:14:24 +08:00 |
|
|
chengma
|
d1165b9e17
|
feat: 重构顺运宝规格主链路 (#88)
|
2026-08-10 12:24:23 +08:00 |
|
|
chengma
|
13cfced80d
|
feat: 迁移 Admin Repository 到 MySQL 8 (#79)
|
2026-08-10 02:21:31 +08:00 |
|
|
chengma
|
155dd3b4a2
|
feat: 统一 Admin 主列表分页 (#64)
|
2026-08-09 21:51:20 +08:00 |
|
|
chengma
|
93beef8b36
|
feat: 保存并展示 PDD 店铺与价格采样信息 (#31)
|
2026-08-07 17:13:25 +08:00 |
|
|
chengmaandClaude Opus 5
|
e40ce5a13c
|
fix: 商品卡在「采集中」无法恢复 (#24)
MarkCollecting 原本只在 pending/failed 时成功，而全库只有客户端提交结果
才会把 collecting 改走。客户端离线、崩溃、任务被删都是常态——一旦发生，
这个商品就永久报废，界面上没有任何入口能救，只能改数据库。
改成 collecting 超过 15 分钟视为已超时，允许重新创建采集任务。
判定在读取那一刻现算，仍是同一条原子 UPDATE，不加后台清理协程：
后台扫要处理"扫到一半客户端正好提交了"的竞态，本项目已经在并发上
栽过两次，能不引入并发就不引入。
15 分钟写成有名字的常量并注明理由：采集本身几十秒到两分钟，加上排队
等客户端来领。宁可短也不要长——采集是只读的，多采一次没有副作用，
而卡死的代价是商品永久报废。
已知取舍：超时后老任务还在队列里，客户端上线可能两个都领走、采两次。
可接受（只读，后一次覆盖前一次），已写进代码注释和 03-data-model.md，
免得后来人当成 bug 去"修"成加锁或加租约——租约和心跳是被明确移除的设计。
时间比较用字符串，依赖 NowISO 产出定宽 UTC。已在 NowISO 上加注释：
改成带时区偏移的本地时间会让这个比较静默失效，不报错但判断全错。
界面两处：超时的显示「采集中（超时）」，否则操作员盯着「采集中」
不知道它已经死了；跳过原因按正在采集/已采集/已删除分类计数，
一个都没建成时告诉操作员还要等多久。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 14:42:54 +08:00 |
|
|
chengmaandClaude Opus 5
|
eb8d357f5a
|
feat: PDD 商品页面 (#18)
打通 Client↔Admin 闭环的一环：录入 PDD 链接 → 创建采集任务 →
客户端领走去采 → 规格和价格显示在页面上。#16 写的 MarkCollecting 和
SoftDeletePddProduct 至此才有生产调用方。
链接解析严格、不做容错兜底：goods_id 上有 UNIQUE 约束，防重全靠它。
猜一个的话同一商品会存成好几行、采好几遍，规格映射还说不清指向哪一行。
短链一律拒绝，卡域名是为了拦"粘了淘宝链接"这种失误。
创建采集任务先占状态再建任务：MarkCollecting 只在 pending/failed 时成功，
同时充当"有没有人已经在采"的判断，与建任务在同一事务里，
所以并发点多次只会建出一个任务（实测 4 并发 → 1 条）。
submit.go 的 collectedData 增加 Dimensions —— 没有它就只能按 Go 的 map
遍历，而 map 无序，同一商品每次刷新"颜色/尺码"的先后都可能变。
顺带修 #16 一处缺陷：EnsurePddProduct 复活分支清空了 skus_json 却漏了
title，导致复活后状态显示"未采集"但标题还留着旧值。
审查打回一次：清理"PDD 链接唯一的录入口"这一过期说法（全库 5 处），
以及 shopee.go 里"空 → no_link"的过期 TODO —— no_link 已在 #16
从 CHECK 约束删除，照写会直接撞约束。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 11:27:06 +08:00 |
|
|
chengmaandClaude Opus 5
|
998c06a2bf
|
feat: PDD 商品数据独立成表 (#16)
原来 pdd_data 是 shopee_products 上的一个 JSON 字段，两个蝦皮商品指向
同一个 PDD 链接时会各存一份、各采一次；collect_status 描述的是 PDD 商品的
状态，却挂在蝦皮商品上，两份可能不一致。
更要紧的是 PDD 商品变动频繁（A 下架就得换 B），而 sku_mappings 只按
shopee_sku_id 做键——换商品后旧映射还在，B 恰好有同名规格但完全是另一件货
时会静默买错，事后查不出来。
改动
- 新增 pdd_products 表：id 主键 + goods_id UNIQUE + 4 个状态值（去掉
no_link，「未填链接」改由 shopee_products.pdd_goods_id 为空表达）+
软删除可复活
- shopee_products 去掉 pdd_data / collect_status / collect_error /
collected_at，pdd_goods_id 改为引用
- sku_mappings 主键改为 (shopee_sku_id, pdd_goods_id)，新增 pdd_option_key。
查映射永远带上当前 PDD 商品，换商品后天然查不到旧映射，不需要删数据；
换回原商品时旧映射直接复用
- 新增 OptionKey()：用 json.Marshal 实现（Go 序列化 map 按键名排序，
天然规范化），不自己拼字符串——规格文字里可能含 = 或 ;。
存映射和查 SKU 必须用同一个函数，各写一遍会静默算出不同结果
- 采集结果改落 pdd_products，新增两条校验：
返回的 goods_id 与请求不符 → 整体回滚拒绝（422），不静默存下；
skus 为空数组 → 置 failed 而非 collected，否则界面显示"已采集"
但数据毫无用处
实施时超出工单但必要的三处
- TaskExists 重构为 GetTaskInfo：原函数只返回蝦皮 goods_id，
而采集结果要按 PDD goods_id 落库，不改取不到正确的键
- 复活时一并清空旧采集结果（skus_json / collect_msg / collected_at），
否则复活后会显示"已采集"但数据是删除前的
- 删除 repository/shopee.go：两个函数签名全变且已迁到 pdd.go，留着是死代码
已验证（Go 1.23.0）
- go vet / gofmt / go test 全过，55 个测试
- 端到端补验了工单未覆盖的 HTTP 层：goods_id 不符返回 422
COLLECT_GOODS_MISMATCH 且整体回滚（skus_json 空、任务仍 claimed、
幂等记录 0 条）；skus 为空返回 200 但状态 failed
遗留
- MarkCollecting / SoftDeletePddProduct 暂无调用方，等界面工单接上
- artifact_ref 存 diagnostics 原始 JSON，未按 client-001:artifacts/... 规范化，
因 Client 侧尚未定义 diagnostics 结构
- 界面未实现（工单明确排除），四个页面仍为骨架
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 10:27:39 +08:00 |
|