中午和哥們一起喝茶
哥們說道:晚上喝酒去啊
我:不去,我女朋友過生日
哥們瞪大眼睛看著我:你有病吧,充氣的過什麼生日
我生氣到:有特麼生產日期的好吧
這下明白了吧
明白了需求,相信大家都會覺得很簡單,不就是一個分組彙總嗎?
客官說的對,但生活總會給我們一點 surprise
通用寫法, SQL Server 和 MySQL 都支援
我們看下查詢結果
正確應該是 86.3,.3 哪去了?
莫非 MyBatis-Plus 有問題?
我們切到 MySQL 試試;將 InterfaceCallTimesServiceImpl 上的資料來源改成 mysql_db
然後重啟,我們再存取: http://localhost:8081/interface/summary?startMonth=202301&endMonth=202302
這說明應該不是 MyBatis 的問題,那不完犢子了?
是不是束手無策了? 也不是,我們可以 Bing 一下的嘛
你會發現說的都是批次 insert 的時候, BigDecimal 有精度丟失
單條插入的時候,是沒有精度丟失的
然後了,大家試出了一條件論: 批次插入資料時,如果插入的資料精度不統一,最終入庫的資料精度統一按最低的精度入庫
雖說我們只是查詢,莫非也需要 精度統一 ?
試試唄,反正又不要錢
重啟,神奇的事情發生了
.3 它回來了! 相信此刻的你肯定有一種與知己久別重逢的激動
回車之後,你會發現,原來你不是一個人在戰鬥
那就去裡面找唄,發現 #1489 跟我們的問題有點像,仔細去讀,發現關聯了 #1912
讀到 1912 的末尾,你會發現又關聯了 #2051,我們去看看 2051
那就是在這裡修復了呀,那它關聯的版本是哪個了?
然後我們在回到我們搜尋 BigDecimal 相關 issue 的時候,你會發現
12.2.0 已經發布了
如果覺得看英文的費勁,那就看中文的:Microsoft JDBC Driver for SQL Server 發行說明
這總看得懂了吧
那就將 mssql-jdbc 升級到 12.2.0 試試
入參不用統一精度,結果也正確了!
但是,又開始轉折了,你以為 12.2.0 就高枕無憂了?
BigDecimal 的問題都延續到 12.3.0 了
此刻大家的心情是怎樣的,請評論區留言
1、當 mssql-jdbc 遇上 BigDecimal ,兩種處理方式
1.1 BigDecimal 型別的入參全部統一成最高精度
1.2 版本升級到 12.2.0 ,但還是有問題,需要考慮業務是否會觸發 12.2.0 的 bug
2、 mssql-jdbc 的 BigDecimal 的問題從 2016 年就開始出現了,到了現在( 2023 )還存在問題,我真的想對官方說一句