最近遇到一個(gè)有點(diǎn)意思的bug，特此記錄一下。

問(wèn)題背景

前臺(tái)參數(shù)：前端請(qǐng)求后臺(tái)接口，上送參數(shù)進(jìn)行查詢，上傳參數(shù)如下：

可知上送為兩個(gè)參數(shù)：activityType: “3”，merchantId: “3a9d21a0d18a4e1c819dac57b1730992”

• 后臺(tái)邏輯

String activityType = vo.getActivityType();
		String merchantId = vo.getMerchantId();
		List<TbMarketActivity> activity = activityMapper.getActivityByMerchantId(activityType, merchantId);

• SQL語(yǔ)句

<select id="getActivityByMerchantId"
            resultType="cn.buyforyou.aipc.small.api.entity.marketActivity.TbMarketActivity">
        SELECT
        <include refid="tbMarketActivityColumns"/>,
        b.product_discount as "productDiscount"
        FROM
        tb_market_activity a
        left join tb_market_activity_product b on a.activity_id = b.activity_id
        <where>
            a.status = '2'
            and a.activity_type = #{activityType}
            and a.merchant_id = #{merchantId}
        </where>
        <if test="activityType != null and activityType = '2'.toString()">
			order by product_discount
		</if>
		limit 1
    </select>

后臺(tái)直接使用前臺(tái)參數(shù)進(jìn)行數(shù)據(jù)庫(kù)查詢，sql日志如下：

 ==> Preparing: SELECT a.activity_id AS "activityId", b.product_discount as "productDiscount" FROM tb_market_activity a left join tb_market_activity_product b on a.activity_id = b.activity_id WHERE a.status = '2' and a.activity_type = ? and a.merchant_id = ? order by product_discount limit 1 
 ==> Parameters: 2(String), 3a9d21a0d18a4e1c819dac57b1730992(String)
 <==      Total: 0

那么問(wèn)題就來(lái)了，中間并沒(méi)有進(jìn)行任何的上傳參數(shù)處理，但是到了SQL語(yǔ)句中，activity_type的值是2，而不是上傳的3

問(wèn)題分析

排查一：確認(rèn)上送參數(shù)

如圖，上傳參數(shù)確實(shí)為3，但是到了sql中還是2，很納悶，確定不是上送參數(shù)的問(wèn)題

• 排查二：SQL語(yǔ)句
  本次sql并不復(fù)雜，就是一個(gè)簡(jiǎn)單的條件過(guò)濾查詢，而且根據(jù)SQL日志來(lái)看，也已經(jīng)成功綁定了

• 排查三：特么沒(méi)有可排查的啦，簡(jiǎn)直就沒(méi)找到錯(cuò)誤，暫定為懸案

反思：為啥上傳和代碼處理都正確，但是SQL賦值出現(xiàn)錯(cuò)誤，明明上傳的activityType為3，可最后的條件是2；但又為啥不是其他偏偏是2呢。。。。。。

問(wèn)題解決

問(wèn)題的關(guān)鍵點(diǎn)就在于為啥偏偏是2身上，仔細(xì)看一下sql語(yǔ)句，這個(gè)activityType還是和2產(chǎn)生過(guò)聯(lián)系的。如下：

這是一個(gè)簡(jiǎn)單的條件判斷，并決定排序字段的語(yǔ)句，但是中間卻使用了等號(hào)作為判斷條件，顯然這兒是不成立的，大抵已經(jīng)找到原因了。
activityType就是在這個(gè)if判斷語(yǔ)句中，被賦值為2的，即使在Mybatis的初始綁定值為3，那這么說(shuō)的話，activityType不為null時(shí)，它的值會(huì)一直為2。
繼續(xù)往下面想,這個(gè)if語(yǔ)句的執(zhí)行順序，應(yīng)該是在執(zhí)行SQL查詢之前，那可以推斷的是，Mybatis在執(zhí)行SQL時(shí)，首先是先將所有的標(biāo)簽轉(zhuǎn)化組裝為SQL，然后在執(zhí)行SQL語(yǔ)句。所以這里就已經(jīng)被賦錯(cuò)了值。

解決辦法也特別簡(jiǎn)單，就是再加一個(gè)=就可以了，標(biāo)準(zhǔn)的判斷語(yǔ)句而已。

補(bǔ)充 ：mybatis的映射文件中，使用的是ognl表達(dá)式，所以在字符串進(jìn)行判等的時(shí)候，可使用以下兩種方法

<if test="sex=='Y'.toString()">
或者
<if test = 'sex== "Y"'>

唯獨(dú)不能使用

<if test="sex=='Y'">

因?yàn)閙ybatis會(huì)把’Y’解析為字符，java是強(qiáng)類型語(yǔ)言，所以不能這樣寫(xiě)。

總結(jié)

確實(shí)覺(jué)得很有意思，一個(gè)很小的錯(cuò)誤，發(fā)生的那么不經(jīng)意，SQL不報(bào)錯(cuò)，頁(yè)面也沒(méi)有錯(cuò)誤，排查起來(lái)確實(shí)費(fèi)了點(diǎn)心，以后寫(xiě)代碼還是得多加注意呀?。?！

到此這篇關(guān)于Mybatis的if從句中的賦值烏龍的文章就介紹到這了,更多相關(guān)Mybatis if從句賦值內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論