 tamakyi
|
d5a011259d
|
导出：按身份把编号对齐到基线（app 只能靠编号解引用地点/活动，编号漂移就「看不到数据」）
背景：Core Data 里**地点与活动没有 UUID**，app 只能靠 Z_PK 解引用（ZVISIT.ZLOCATION /
ZVISIT.ZACTIVITY_）。站点这边的 src_pk 是从「导入→导出」循环里滚出来的，与手机 store 的 Z_PK
不是一套。2026-09-29 实测（真机 09-28 包 vs 站点导出，按到访 UUID 对齐）：地点引用 920/920 不同、
活动引用 903/920 不同，而引用到的地点按「名称+坐标」完全一致——语义相同、编号不同。结果就是
「导入成功但看不到数据」（每条到访都指到手机那边的别的地点/活动或不存在的行）。
做法（新增 internal/rond/export_align.go）：导出的每张托管表**先按身份建映射**，再按映射后的编号写：
地点：坐标键优先（多值索引），退到「同名且相距 ≤1km」
活动/到访：UUID（读留档 entity_raw 里的 ZUID_ / ZIDENTIFIER_）
标签/交通方式：名称；位移/天气：所属到访（已对齐）
基线里没有身份对应的行 → 取基线最大编号之上的新号；而**身份匹配不上、原编号又没被别的身份占用的行
保持原编号**（这样「基线就是源包」的往返导出一行都不动；被占用时才另取号，避免覆盖基线的别的记录）。
配套改动：引用全部改挂（含自引用 ZMERGEDTO / ZPARENT，它们原本从留档原样带出、对齐后会指错或悬空，
已加入托管列并按映射写回）；Z_PRIMARYKEY.Z_MAX 改用实际写入的编号；基线身份查询都 ORDER BY Z_PK 保证
确定性；siteUUIDMap 改成读 base64 后在 Go 里解码（与 web 侧 loadStoredVisits 同一手法）。
验证：
- 真实数据（本地数据集 + 真机 09-28 当基线）：按 UUID 对齐的 953 条共同到访里地点引用一致 933、
活动一致 951（改前 0 / 7），悬空引用 0；余下 20 条是基线自己重名重复行的归属歧义。
- 用例 TestExportAlignsPKsToBaseline：把库内编号整体平移 500000 再导出，断言按 UUID 对齐后**地点/
活动的编号**与基线一致率 ≥95% + 7 类引用无悬空 ⇒ 822/822。⚠️ 第一版只比「名称+坐标」，变异验证
不会变红（编号不一致时引用依然自洽），必须比编号本身。
- 往返不变量 TestExportRoundtrip 通过（「匹配不上则保持原编号」这条规则就是为它加的：之前唯一的
未匹配行是那条没有 UUID 的「全空到访」，被改号成 825 才暴露出来）。
- 全量验收 297 PASS / 0 FAIL / 0 SKIP。
注意：对齐的目标是**这份数据集的基线**。要让导出与手机编号一致，数据集的基线就得是手机包
（把手机导出作为新数据集上传、再把旧站点导出包合并进去，然后从它导出）。
|
2026-09-29 16:57:29 +08:00 |
|