MybatisPlus批量更新的小插曲

发布时间:2024年01月23日

插曲背景

在商城项目中涉及订单业务,有两个主要的表:订单表order和订单明细表order_detail。

  • order表:主要存储订单的主要信息,订单总金额,收货人信息,订单状态等;
  • order_detail表:主要存储订单购买的商品明细信息,每个SKU一条记录;

order表和order_detail表的主键id都是自增的,order表有一个sn字段,order_detail表有一个order_sn字段,这两个表通过sn和order_sn两个字段进行关联,实现业务:1个订单有多少条订单明细记录。

插曲描述

项目增加一个状态同步需求:更新order记录的状态status,同时更新对应的订单明细记录的status。

在开发环境联调测试都是ok的:下单 -> 更新订单状态。然后,在sit测试环境出现一种奇怪的现象,执行状态更新操作之后,指定订单对应的所有的订单明细记录数据全部都变成一样了,且每条记录的id均为0。

因为之前订单功能是已上线的,且数据库变更的管理采用flyway组件,同样的代码在不同的环境执行效果不一样,只能猜测是环境不一样导致的。

开发人员没有sit环境数据库的更新权限,只有只读权限。

问题排查

在更新逻辑代码中增加执行日志输出,重新提测之后。观察操作执行的日志,发现:在【下单】操作之后,生成的订单明细记录id均为0;继续执行更新操作时,所有的订单明细记录数据全部更新为相同的数据。批量更新使用MybatisPlus的updateBatchById方法。

针对上述情况,第一反应是原本自增的id字段值为啥都是0?查看一下sit环境order_detail表的设计语句,发现id字段没有被设置为:自增。再核对了开发环境order_detail表的设计语句,id字段是自增的。

造成问题的原因出来了:sit环境和dev环境的表结构不一致了。将sit环境order_detail表的id设置为自增,重新测试该需求功能,好了!

问题反思

  1. 越让人放心省力的方法,一旦出现问题,越不好排查问题(通过flyway保证各个环境的数据表结构一致,也要小心使用);
  2. 敢于质疑,由于一开始并没有想到会是环境不同导致的问题,一致代码层面排查,所以浪费了时间,比如:修改可疑的代码,增加日志输出等工作。
文章来源:https://blog.csdn.net/xiaohui249/article/details/135770748
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。