mgm-daylight-mcrm-api-mobile/docs/merge_daylight_dl_reservation_dedup.md

Daylight 合并与 dl_reservation_id 去重说明

本文档说明 BookingService 中为减少「同一 Daylight 预订在 bookings 表出现多行」所做的修改及调用关系。

---

1. 涉及文件与入口

位置	说明
BookingService.java	mergeDaylightRecordToDatabaseInfo、insertDaylightBooking、consolidateDuplicateDlReservations 及相关私有辅助方法
BookingController（recordSearch 等）	在拉取 Daylight 列表后调用 mergeDaylightRecordToDatabaseInfo

---

2. mergeDaylightRecordToDatabaseInfo 的改动要点

2.1 预查询：按 dlReservationId 收集（不再依赖确认号）

原问题：仅当 confirmationNo 非空时才把 dlReservationId 放进 findByDlReservationIdIn 的入参。若接口有 dl_reservation_id 但尚未返回确认号，则查不到库里已有行，会误判为「不存在」而走插入，产生重复。

现逻辑：对本次 result（Daylight 返回列表）中每条记录，只要 dlReservationId 非空白即加入 LinkedHashSet，再转为 List 做 findByDlReservationIdIn。

2.2 合并后物理去重：consolidateDuplicateDlReservations

在 updateBookingList 执行 bookingDao.saveAll 之后，对本次涉及到的每个 dl_reservation_id 再查库：

• 若同一 dl_reservation_id 仍对应 ≥2 行（例如一条前台 PN、一条同步误插入的 N），则：
  • 按评分规则选出 keeper（主行），其余为 duplicate（次行）；
  • 将次行上可对齐的字段并入主行后 delete 次行。

主行评分 keeperScoreForDlDedup（分数高者优先）：

• 有 player_id：+1000
• approve_status == "PN"：+100
• 有 confirmation_no：+10
• 有 member：+5

同分按 较小 id 靠前（作为 keeper）。

不合并、不删除 shouldSkipConsolidatingDuplicateRow：

• 次行 approve_status 以 W 开头（候补等）
• 次行 revision_of 指向 keeper（待审批修订子单）
• keeper revision_of 指向次行

字段合并 mergeDuplicateBookingIntoKeeper：

• 确认号、resv_id、Opera 状态、酒店/客源/房价码、player_id、member 与姓名字段、房/房型、booking_type_id、chain_code、block_id 等在主行为空或可从次行安全补齐时写入主行；last_opera_status 若次行有值则写入主行（与 Opera 同步一致）。

日志前缀：[consolidateDuplicateDlReservations]。

---

3. insertDaylightBooking 的改动要点

3.1 按 dl_reservation_id 兜底防插

在组好 Bookings book 并准备 save 之前，若 operaBooking.getDlReservationId() 非空，则先 findByDlReservationIdIn：

• 若已存在任一行：不再 save 新单，打日志 [insertDaylightBooking] skip insert, existing dl_reservation_id=...，并设置返回视图上的 id 等为已有记录，直接 return operaBooking。

避免「合并阶段漏匹配」时再次插入第二条同 dl_reservation_id。

3.2 按确认号防重（空列表才插入）

• 仅当 confirmationNo 非空时执行 findByConfirmationNo；
• 仅当查询结果为空 时才 bookingDao.save(book)；
• 若已有同确认号记录，则复用其 id，不重复插入。

---

4. 根因归纳（与旧版对比）

原因	说明
预查漏掉无确认号的 dl_reservation_id	已用 LinkedHashSet + 非空 dlReservationId 修复
仅合并不删重复行	已用 consolidateDuplicateDlReservations 在当次同步末尾收敛
插入路径无 dl_reservation_id 防重 / 确认号逻辑不当	已在 insertDaylightBooking 中补齐
数据库无唯一约束	仍建议在库上对非空 dl_reservation_id 做过滤唯一索引（上线前清理历史重复）
并发双写	当前以逻辑合并 + 完成后去重为主；多实例强一致可再加分布式锁或 DB 唯一约束

---

5. 运维与验证

1. 验证：部署后对曾出现双行的会员再触发一次会走 mergeDaylightRecordToDatabaseInfo 的查询（如 recordSearch）；观察日志中 consolidateDuplicateDlReservations 是否合并并删除次行。
2. 历史数据：长期未再走合并流程的重复行，需一次性脚本或手工按业务规则保留主行、删除/归档次行。
3. 外键：若 delete 次行失败（子表引用），需先迁移或删除子表记录后再删。

---

6. 可选后续增强（未列入当前分支必选）

• 合并匹配改为 Strings.CI.equals（忽略 dl_reservation_id 大小写），与接口/库实际存储一致。
• 对 mergeDaylightRecordToDatabaseInfo 增加 @Transactional(rollbackFor = Exception.class)，使 saveAll 与 consolidateDuplicateDlReservations 同事务回滚。
• 高并发下对同一 dl_reservation_id 的插入加应用层锁或依赖唯一索引 + 捕获冲突后改走更新。

---

文档与 daylight_1.0.0 分支中 BookingService 当前实现对应；若行号随重构变化请以方法名为准。