qData v1.6.7 更新：增量同步修复后，我会先查哪些地方
这种修复，比新功能更该看一眼
qData 数据中台开源版 v1.6.7 的发布摘要提到了消息通知、时间范围增量读取和 ETL 字段处理的修复。乍看是一次普通维护更新，我反而会把它留在待看列表里。数据链路最让人头疼的，往往是任务看起来跑完了，下游却拿到了不完整的数据。
基于公开摘要可见，这次更新针对实际使用中发现的功能问题。但摘要没有交代触发条件、受影响的配置，也没有给出修复前后的行为对照。下面聊的是升级时我会检查什么，不能把这些检查项当成 qData 已确认存在的缺陷。
增量读取，先问边界怎么算
假设一个同步任务按更新时间读取订单，上一轮结束和下一轮开始都落在同一个时间点。边界是否包含，直接关系到那一刻的记录会不会重复读取或被跳过。标题提到了时间范围增量读取问题，但具体是哪种边界错误，仅凭摘要无法判断。
这事放到实际项目里，我会准备一份小样本，放入恰好落在窗口边界的记录，再让两个相邻窗口连续跑一遍。除了比总条数，还要按业务主键查差异。总数一样也可能是漏了一条、又多了一条。若目标端允许重复写入，测试通过之前别急着放大同步范围。
时间精度也得跟着查。数据库字段保留的精度，未必和任务参数传入的精度相同。至于迟到更新、失败重跑后从哪里继续，属于这条链路本来就该验证的约定，不能指望装上一个修复版本便自动解决。
通知恢复了，不等于数据正确了
消息通知修复很容易被当成界面上的小调整。可如果值班的人靠它接收失败消息，升级验收就不能只看测试按钮能否发出通知。我更关心的是：真实任务失败后，消息能不能到达接手的人，里面有没有足够的信息找到任务和日志。
反过来，也别把收到成功通知当成数据验收。可以挑一张业务表，核对同步时间段内的主键集合和必要字段；碰到涉及字段转换的任务，再检查空值、类型转换失败时的处理结果。这些是通用回归建议，不代表本次 ETL 修复就涉及这些情况。
回滚版本容易，回滚数据未必
如果现有任务运行稳定，我不会只凭发布标题立刻全量升级。先找完整变更说明，确认当前版本是否受影响；再选一个能重放、输出可核对的任务试跑。小团队尤其要控制试跑范围，别让一次验证变成下班后的补数工程。
升级前还应保存任务配置和当前读取进度，并弄清楚新版本写出的数据怎么撤回。程序回退以后，目标表不会跟着恢复原样。若只能靠重跑补救，就先确认重跑不会重复记账或覆盖正确记录。这次更新是否适合马上装，我会看自己的回归结果，而不是修复列表有多长。
本文由本站基于公开热点摘要整理和原创分析生成。来源：OSCHINA：qData 数据中台开源版 v1.6.7 发布：修复消息通知与时间范围增量读取问题。
