 tamakyi
|
78865fc736
|
导出：删掉到访后，别把它指向的原始采样点留成悬空引用
真机报「备份恢复失败，你的当前数据未被更改」——这句说明它是先校验、整体回滚。
往下查的第一个醒悟：**Core Data 的 SQLite 表里根本没有外键约束**（关系由 Core Data
自己维护），所以之前跑的 PRAGMA foreign_key_check 报 0 违例毫无意义，它压根没得可查。
按关系列手查悬空引用，结果：
原版：悬空 0
导出：ZRAWVISIT.ZVISIT 有 2 条指向不存在的 ZVISIT —— (2051→到访46, 465→到访200)
正是用户在站点上删掉的那两条到访。ZRAWVISIT（原始 GPS 采样点）是不托管实体、
导出时原样保留，于是删到访就留下了指向已删记录的悬空关系；而真机删到访时
采样点是跟着级联删的，所以这是它自己绝不会产生的形状。
修法：visit.finish() 之后，删掉 ZVISIT 指向不存在到访的 ZRAWVISIT 行。
选「删」而不是「把 ZVISIT 置空」：真机的「未归并采样点」虽有 1461/2246 条（置空合法），
但留成未归并会让 app 重新推出一条到访，把用户删掉的记录复活。
顺带加固：
- verify_export_structure.py 新增 1.45 节「关系完整性」，手查 8 组关系列的悬空引用，
有悬空就把结论判成「有差异」——这条 foreign_key_check 查不出来的坑进了标准验收清单。
- TestExportDropsOrphanedRawVisits：删一条带采样点的到访 → 导出 → 断言没有悬空；已做变异验证。
|
2026-09-20 18:05:47 +08:00 |
|
|
tamakyi
|
56c7283e38
|
导出：新建的交通方式别把颜色/图标写成 NULL
排查「导出包导不回真机」时逐列比对发现的唯一实质缺陷：
站点新建的交通方式「步行」导出来是 ZCOLOR_=NULL / ZICON_=NULL，而真机原有 5 条
（火车/公交/高铁/电🐔/地铁）全部有值 —— 真机这两列从不写 NULL、也不写空串。
成因链：站点不单独维护交通方式表（颜色/图标是从 movements 上聚合的），
建方式时没选就存成 NULL，queryTransports 的 FILTER (WHERE ... IS NOT NULL) 聚成 NULL，
ns() 又把空串和 NULL 一起变成 nil，写进包里就是 NULL。
修法：只给**新建的行**补占位（gray / circle.fill），基线里已有的行不碰 ——
那种情况 keepNilCols 会保留真机原值，擅自补占位反而会把真值盖掉。
与「新建活动补 blue/📍」同一套做法。
同时加一条通用的守卫（export_placeholder_test.go）：判据是
「基线里 100% 有值的列，导出里的新行也不许为空」，对所有托管表逐列扫。
只修 ZTRANSPORT 是治标，这条才是同类问题的根治办法。已做变异验证。
|
2026-09-20 17:37:04 +08:00 |
|
|
tamakyi
|
30c502ce7b
|
备份与迷雾的差异分析、合并执行，附属数据改挂坐标键
备份（.rondbackup）与迷雾（.fwss）各加一层「先看差异再动手」：
- 迷雾：上传先出差异页，说清叠加能补多少、整体替换会丢多少，并在真实底图上
用绿/灰/红标出会新增 / 不变 / 会丢的区域
- 备份：与当前数据集按 UUID 逐条比对（rond 每次导出都会重排 Z_PK，编号认不出人），
新增合入、冲突逐条选、仅站内有逐条勾选删除，全在一个事务里执行；
合入的行写回 entity_raw，保证再传同一份备份时差异归零
- 地点按坐标对齐：站点的「补全地址」会把地点改名，拿名称当键会让一整个地点的
到访全变成假冲突
- 附属数据（备注/结论/访客票/图片）从 dataset_id+src_pk 换成坐标键，换数据集不再失联；
访客票没有 dataset_id，回填按活跃数据集认领
- 修正 contentHash 拿 Z_PK 当指纹的隐患，以及两处「src_pk 跨快照稳定」的错误注释
导出格式（.rondbackup / .fwss）保持原样，往返测试通过。
|
2026-09-19 16:04:00 +08:00 |
|
|
tamakyi
|
b327bc1230
|
first release
|
2026-09-18 13:05:49 +08:00 |
|