乌龙!mybatis-plus的@TableId注解不生效,原来竟是因为它!

【先来个小测试】

大家觉得下面的sql返回什么?

select * from table1 where null=1

 

答案:无返回。因为null=1是个false的表达式。这就像我们写where 1=2一样。

 

【↓↓正文开始↓↓】

需求开发完成,将开发分支merge到test分支,部署测试环境提测后,QA提了一个bug,附下面log截图。 


通过logtrace排查程序,定位到如下代码。代码很简单,调用mybatis-plus的getById函数按主键查数据得到entity对象。PayMerchantBankCardFlow这个实体类里在主属性里是标记了@TableId的。那么,mybatis-plus底层拼接sql时,怎么没有把主键字段拼出来呢?

PayMerchantBankCardFlow bankCardFlow = payMerchantBankCardFlowManager.getById(cardBindDTO.getFlowNo());

 

@TableName(value = "pay_merchant_bankcard_flow",autoResultMap = true)
public class PayMerchantBankCardFlow implements Serializable {

    private static final long serialVersionUID = 5112092241305418545L;

    /**请求流水号*/
    @JsonSerialize(using= ToStringSerializer.class)
    @TableId(type = IdType.ID_WORKER)
    private Long flowNo;

 

这确实令人费解!当时我在参加一个代码评审会,修复bug优先,于是临时在PayMerchantBankCardFlowManager里重写了getById。然后发布让QA继续后续的功能测试。

public class PayMerchantBankCardFlowManager{

    @Override
    public PayMerchantBankCardFlow getById(Serializable id) {
        return getOne(Wrappers.query(new PayMerchantBankCardFlow().setFlowNo((Long) id)));
    }

 

bugfix就算完事了吗?不,作为靠谱的程序员,我们有必要对这个bug查明原因。

一个小伙在本地通过junit测试,发现getById是没问题的。当然,凭借我们历往对mybatis-plus的掌握程度,这个@TableId必然不会有问题的。

但是结论呢?为什么本地没bug而测试环境有bug呢?

这时就考验技术人员的综合能力了。

还是组内的jason同学协助给破解了。

原来,在test分支里,PayMerchantBankCardFlow#flowNo的@TableId注解被别的开发分支给合没了。这下就真相大白了。

最终修正代码,还原临时改动的代码,这个乌龙事件得以消停。

 

 

 

热门相关:我的嫂子   爱爱对减肥的影响   一屋三户   怨妇·淫娃·疯杀手   这三洨电影