tamakyi/rond-with-you
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
37 Commits 1 Branch 0 Tags
8763b850bee41df3d3ddddbd1cc7d9c679741231
Commit Graph
9 Commits
Author SHA1 Message Date
tamakyi 8763b850be 合并：地点配对只留一份实现（rond.MatchPlaces），合并侧不再自己配一遍 
- 抽出 rond.MatchPlaces(stored, backup) PlaceMatch：坐标优先、退到「同名且相距 ≤1km」、
  多值索引 + 认领即标记已用；DiffPlaces 与 web.mergePlaces 共用它。
- mergePlaces 原来是单槽位 byCoord/byName 自己再配一遍：同坐标/同名的多条备份地点全并到同一行
  站内地点，到访被挂到错的分店（实测「茶颜悦色」两家分店相隔 8.3km，到访却指着同一条）。
  现在直接用配对结果，再叠加 plan.AddPlaces 的新插入。
- loadStoredPlaces 与 mergePlaces 的地点查询都加 ORDER BY id：候选多于一个时靠顺序定谁配谁，
  两侧必须一致，否则配对会飘。
- 删掉只写不读的 PlacePatch.CoordKey、ActivityPatch.Key（容易被误当成查找键）。
- 用例：TestMatchPlacesKeepsDuplicateNameGroupsDistinct（同一坐标/邻近同名都要一条配一条）、
  TestMergePlacesMapsSameNameLocationsOneToOne（真库 + 真事务，两条同名备份地点必须映射到两条不同
  地点）；两处都做了变异验证（认领不标记已用 / 恢复单槽位映射 → 对应用例变红）。
- 探针库复测（从 dump 恢复、不动本地真库，49 组冲突全「用实机」）：到访挂错地点（>1km）0/953 条、
  地点被搬动 >1km 0 个；合并后再比对三类全 0（到访 0/47/0、地点 0/4/0、活动 0/0/0），
  再点合并「按当前的选择没有要写入的改动」。全量验收 293 PASS / 0 FAIL / 0 SKIP。

已知取舍：勾「用实机」但没勾「并进来」时，若该到访在实机上的地点站内没有、且按 1km 规则也配不上，
place_id 会被置空（旧行为是挂到一条远方的同名地点上——那正是这次要去掉的错配）。
 2026-09-29 10:46:54 +08:00
tamakyi 370c4285f8 合并：按名称兜底配对加 1km 上限，冲突行在名称相同时把坐标印出来 
- DiffPlaces 的 takeByName 只在两点相距 ≤1km 时才认领：名称不是唯一键，连锁店同名是常态
  （真机里「中国体育彩票」3 条、「长沙南站」2 条、「茶颜悦色」2 条）。没有上限时，坐标配不上
  的两条同名地点会被强行配成一对——实测把佛山的「中国体育彩票」配给了贺州那条（直线 236.8km），
  站长勾「用实机」就把站内那条地点的坐标搬到另一座城市（实测 src_pk=71 从贺州搬到佛山）。
  注意 geo.Haversine 返回的是公里，常量按公里写。
- visitFieldChanges 的「地点」在两边名称相同时用 coordSuffix 把坐标印出来：这一项比的是坐标，
  只印名称会渲染成「X → X」，站长看不出差在哪（连锁店重名、同一地点两边坐标略有出入都会走到这里）。
- 新增用例 3 条（相隔 236.8km 不该配对、665m 仍要配对、名称相同时必须带坐标）+ 变异验证。
- 复测（回滚后按浏览器默认全选「用实机」重跑）：被搬动超过 1km 的地点从 1 个变 0 个；
  合并后再比对 到访 0/47/1、地点 0/4/1、活动 0/0/0；953 条 UUID 到访全命中、到达时间 0 偏差。
 2026-09-29 10:18:22 +08:00
tamakyi 10d23e03cf 合并：重复地点不再反复判「备份新增」，到访的活动改按身份比 
- DiffPlaces 的 byCoord/byName 改为多值索引 + take() 逐条认领未用项：真机一个坐标下会有
  多条同名同坐标的地点（实测「柳州站」3 条），单槽位时同一坐标最多只配上 2 条，第 3 条
  永远判「备份新增」⇒ 每次合并都再插一条重复地点、差异永远归不了零（实测 368→438→439）。
  修完：地点新增 70→67、合并后再比对归零、再点合并直接「没有要写入的改动」。
- 到访的「活动」由按名称比改为按身份（ZUID_）比，两边都缺 UUID 才退回名称：16 个活动改名
  曾把 355 条到访全变成同因冲突，且逐条选「用实机」只写回 activity_id（映射回同一个活动）
  改不掉名字。loadStoredVisits 为此多 JOIN 一次 entity_raw 取 ZACTIVITY.ZUID_。
- 回归用例 4 条（重复地点一一配上、活动改名不算冲突、换活动仍要报、缺 UUID 退回名称）+
  「合并后地点差异归零」断言 3 处；两处改动都做过变异验证。
- 实测（09-28 备份并进 09-14 数据集）：到访冲突 253→6，合并两次地点数 438→439 变为 435→435。
 2026-09-28 19:31:21 +08:00
tamakyi 05c6e970db 测试：补 rond 合并冲突与 gpx 解析用例，删两处死代码 2026-09-24 22:48:22 +08:00
tamakyi b4c2a8452f 审计修复：后端（安全 / 数据一致性 / 性能） 
audit-2026-09-21.md 里的后端条目落地。每条都配了回归守卫，并逐条做过变异验证
（注入原 bug → 确认按正确理由变红 → 还原 → 变绿）。

安全
- CSRF 只加同源 Origin/Referer 守卫（csrf.go），不动模板
- 会话 cookie 的 Secure 按请求判断；两步验证两闸（loginGuard + 验证码一次性）
- 跳转收口到 safeInternalPath；clientIP 只认 XFF 最后一段
- GPX 按属主圈定且查 RowsAffected；下载名走 downloadDisposition
- 上传口统一 MaxBytesReader；落盘后的失败路径清掉半成品

数据一致性
- 区域判定两端各过一遍再 AND（apiTrack 与 movementsWhere 对齐）
- Filter.Verdict 全域一致（下推到 visitsWhere）；聚合刷新必须返回 error
- 附属数据改挂坐标键，Go 与 SQL 两套表达式逐位一致
- 脏备份的伪时间/越界坐标不再进领域模型；rows 循环统一 drainRows
- 合并与导出：writeRawRow 上抛错误、悬空引用清理、原生列补全

性能
- placeCols 相关子查询带 dataset_id 前导列；findSourceArchive 先按大小筛
- 批量勾选改 ANY($3::bigint[])；fillupCache 加上限；同一查询不再查两遍

另：新增「全新库」冒烟测试 —— 空库跑完 Migrate 再用应用侧读查询真打一遍，
迁移块排到依赖表之前这种错只有新库会炸，老库毫无症状。
 2026-09-24 20:37:16 +08:00
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