【先來個小測試】 大家覺得下麵的sql返回什麼？ select * from table1 where null=1 答案：無返回。因為null=1是個false的表達式。這就像我們寫where 1=2一樣。 【↓↓正文開始↓↓】 需求開發完成，將開發分支merge到test分支，部署測試環境提測後 ...
【先來個小測試】
大家覺得下麵的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註解被別的開發分支給合沒了。這下就真相大白了。
最終修正代碼，還原臨時改動的代碼，這個烏龍事件得以消停。
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請註明原文鏈接：https://www.cnblogs.com/buguge/p/17862888.html
