为比价记录补充是否下单状态 #184

2026-07-27T14:57:17+08:00

linkeyu commented

2026-07-27 14:57:17 +08:00

改动说明

后台比价记录列表与详情增加 ordered 字段
按当前页批量查询真实下单记录，避免逐行查询
判定口径与 C 端一致：同一用户、同一店铺且 source=compare
demo 数据不计为真实下单
增加列表和详情接口回归测试

验证

tests/test_admin_read.py：19 项通过

## 改动说明 - 后台比价记录列表与详情增加 ordered 字段 - 按当前页批量查询真实下单记录，避免逐行查询 - 判定口径与 C 端一致：同一用户、同一店铺且 source=compare - demo 数据不计为真实下单 - 增加列表和详情接口回归测试 ## 验证 - tests/test_admin_read.py：19 项通过

linkeyu added 1 commit 2026-07-27 14:57:19 +08:00

功能：为比价记录补充是否下单 51ce90afef

后台比价记录列表和详情按真实下单口径批量标记下单状态，并增加接口回归测试。

linkeyu added 1 commit 2026-07-27 16:17:01 +08:00

合并：解决比价下单状态与最新主干冲突 959d2d53e7

guke referenced this pull request

2026-07-27 16:37:51 +08:00

修复比价记录机型与 ROM 版本展示 #183

linkeyu added 1 commit 2026-07-27 16:43:41 +08:00

合并：兼容比价设备信息与提现汇总更新 e2d6e72d23

guke commented

2026-07-27 17:24:10 +08:00

🤖 review-pr 深审结论

🟢 可以合并（置信度 0.9）。逻辑正确、与 C 端既有口径一致，实跑测试 + lint 通过。

已实跑验证（worktree 隔离副本，未污染工作区）：

pytest -k "comparison or order_status" → 4 passed。新增 test_comparison_records_show_real_order_status 覆盖了列表 + 详情两个端点，并校验了 source='compare'（真实下单）与 source='demo'（演示）的区分。
ruff check 改动文件 → 未引入新告警（仓内 13 处 UP017 均为既有问题，行号都在本 PR 改动范围之外）。
分支已基于当前 main（base sha == origin/main head），无需合并、无冲突。

写得对的地方：

_attach_comparison_order_status 把 C 端单用户的 _ordered_shop_names 正确泛化到 admin 多用户场景：按 (user_id, shop_name) 配对匹配，避免了「A 用户在某店下过单，把 B 用户同店的比价也标成已下单」的跨用户误判。
单条批量查询 + .distinct()，遵循 _attach_user_info 的逐页范式，无 N+1。
user_id 为空（孤儿行）、store_name 为空/空串都正确落到 ordered=False。
ordered 是瞬态属性（非 ORM 列），详情 schema AdminComparisonDetail 继承 AdminComparisonListItem 自动带上该字段，详情端点已被测试覆盖。

一条 FYI（非阻塞，low）：

店级归因：同一家店比价多次会被一并标「已下单」（即便其中某几次并未真正下单）。这是 C 端既有口径 —— SavingsRecord 上报不带 trace_id，只能按店名对齐，无法「按单次比价」精确归因，故一致且可接受。仅提示：该列的语义是「该用户在该店有过真实下单」，不是「这一条比价导致了下单」；若产品预期是后者，需上报侧补 trace_id 才能实现。

建议：可直接合并；与前端 admin-web #88 同批发布。

## 🤖 review-pr 深审结论 🟢 **可以合并**（置信度 0.9）。逻辑正确、与 C 端既有口径一致，实跑测试 + lint 通过。 **已实跑验证（worktree 隔离副本，未污染工作区）：** - `pytest -k "comparison or order_status"` → **4 passed**。新增 `test_comparison_records_show_real_order_status` 覆盖了列表 + 详情两个端点，并校验了 `source='compare'`（真实下单）与 `source='demo'`（演示）的区分。 - `ruff check` 改动文件 → **未引入新告警**（仓内 13 处 UP017 均为既有问题，行号都在本 PR 改动范围之外）。 - 分支已基于当前 `main`（base sha == origin/main head），无需合并、无冲突。 **写得对的地方：** - `_attach_comparison_order_status` 把 C 端单用户的 `_ordered_shop_names` 正确泛化到 admin 多用户场景：按 `(user_id, shop_name)` **配对**匹配，避免了「A 用户在某店下过单，把 B 用户同店的比价也标成已下单」的跨用户误判。 - 单条批量查询 + `.distinct()`，遵循 `_attach_user_info` 的逐页范式，无 N+1。 - `user_id` 为空（孤儿行）、`store_name` 为空/空串都正确落到 `ordered=False`。 - `ordered` 是瞬态属性（非 ORM 列），详情 schema `AdminComparisonDetail` 继承 `AdminComparisonListItem` 自动带上该字段，详情端点已被测试覆盖。 **一条 FYI（非阻塞，low）：** - **店级归因**：同一家店比价多次会被**一并**标「已下单」（即便其中某几次并未真正下单）。这是 C 端既有口径 —— `SavingsRecord` 上报不带 `trace_id`，只能按店名对齐，无法「按单次比价」精确归因，故一致且可接受。仅提示：该列的语义是「该用户在该店有过真实下单」，不是「这一条比价导致了下单」；若产品预期是后者，需上报侧补 `trace_id` 才能实现。 **建议**：可直接合并；与前端 admin-web #88 同批发布。

guke merged commit b5962464e8 into main

2026-07-27 17:33:10 +08:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: WonderableAI/shaguabijia-app-server#184