错误案例
短信平台长短信小需求预发布时,发现短信的发送速度忽然变得很慢。
检查webx.log日志:
Caused by: com.ibatis.common.exception.NestedRuntimeException: Error setting properties of 'gmtModified=[null], gmtExpire=[null].....(省略不重要的日志)
Caused by: java.lang.IllegalArgumentException.....(省略不重要的日志)
原因是查询结果映射转化时抛出了异常,异常抛出的位置是在设置groupSeq和groupCount值的时候。
错误分析
长短信小需求往sms_out表中新添加number类型字段group_seq和group_count,对应DO中的属性groupSeq和groupCount是int类型。
发布前4小时,dba先对表结构做了变更,所以线上group_seq和group_count字段的初始值都是null的。
因为原来的代码不会使用新加的字段,所以表结构变更后对程序不会有影响。
等到小需求发布以后,新加字段就起作用了。
虽然新上的代码可以保证新插入sms_out表中的记录group_seq和group_count这两个字段不会为空,但是在sms_out表中会残留这两个字段null的记录。
(系统设计上sms_out为记录短信发送的中间表,无论发送成功失败,这张表中的记录最终都会被清空,但是还是很难保证发布时,表中没有新增字段为null的记录。)
所以在对sms_out表做查询操作后,把查询结果映射为DO时,null就要被转成int类型,于是抛出了异常。
正确用法
1、结果集映射时对为null的数据做兼容性处理。例如:查询结果number类型字段为空时赋值为0
<result property="groupCount" column="GROUP_COUNT" javaType="int" jdbcType="NUMBER" nullValue="0"/>
2、可以考虑让dba订正数据时在number类型的数据上附上初始值
3、可以考虑使用Integer类型,而不是基本类型int
测试关注点
自测遗漏原因:
sms_out表中存储放的是中间数据,一旦短信成功发送,sms_out表中的数据会被清空。
在自测时是sms_out表为空,而新的程序跑出来的数据新加字段又不可能为空,所以自测时遗漏了这一点。
对应新加字段时,测试需要考虑:
1、需要考虑原有数据新字段的初始值,尤其是对为null情况的处理。
2、老程序对新加字段的兼容性问题(要考虑小需求发布失败需要回滚的情况,原则上dba不允许新加字段回滚)。