mybatis in查询传入String
在使用 mybaits 进行 in 查询时,传入String,如1,2,3,发现查询的结果并非我们想要的
这是因为#{}编译完自动加双引号“” 也就是变成in (“1,2,3”)
如果想要获得我们想要的结果,可以使用${},编译完是这样的 in (1,2,3)
例如,查询铃音库中多首铃音的总数量
1
2
3
4
5
6
7
8
|
< select id= "getProgsResourceCount" resultType= "java.lang.Long" parameterType= "com.progandresource.entity.ProgsResourceCond" > select count (ring_no) from progandresmanage_ringinfo where valid_day > now() <if test= "ringNo != '' and ringNo != null" > and ring_no in (${ringNo}) </if> </ select > |
如果传入参数是List或者Array,则直接用foreach即可
例如
1
2
3
4
5
6
7
|
< select id= "getProgsResourceCount" resultType= "java.lang.Long" parameterType= "java.util.List" > select count (ring_no) from progandresmanage_ringinfo where valid_day > now() and ring_no in <foreach collection= "list" item= "item" index = "index" open = "(" close = ")" separator= "," > #{item, jdbcType= VARCHAR } </foreach> </ select > |
mybatis in查询传入字符串参数
sql里的in操作符允许我们在where子句中规定多个值进行匹配。
语法:
1
2
3
|
SELECT column_name(s) FROM table_name WHERE column_name IN (value1,value2,...); |
在mybatis里,可以通过传入数组或容器(array、list、set、map)通过foreach标签来给in操作符指定参数。
问题:想要从org表中匹配字段org_id在OR001、OR002、OR004中的数据,org_id是字符串类型的字段。
常规方法是在mapper.java中传入一个包含"OR001"、“OR002”、"OR004"的list对象orgIdList,在xml中:
1
2
3
4
|
SELECT * from org where org_id in <foreach item= "orgId" index = "index" collection= "orgIdList" open = "(" close = ")" separator= "," > #{orgId} </foreach> |
如果要作为in的匹配参数的多个值在一个String类型的对象orgs中,想直接通过String传入,有两种实现方式。
1、在xml中用${orgs}把整个String作为sql的一部分
1
|
SELECT * from org where org_id in (${orgs}) |
这种写法需要关注字符串orgs的内容在拼入之后,整个sql是否是符合语法的,按上面的需求和sql写法,就要求作为sql一部分的orgs的值为"‘OR001',‘OR002',‘OR004'"。
参数直接以sql一部分的方式作为查询语句存在sql注入的风险,有一些项目可能会一刀切地限制开发者不允许用这种写法。
2、在xml的foreach标签里,传入collection属性时将字符串用split函数转为数组
1
2
3
4
|
SELECT * from org where org_id in <foreach item= "orgId" index = "index" collection= "orgs.split(',')" open = "(" close = ")" separator= "," > #{orgId} </foreach> |
在这里传入的orgs字符串的值可以为"OR001,OR002,OR004",在调用split函数时设置","分格,可以直接切分出三个字符串作为数组的元素。
以上为个人经验,希望能给大家一个参考,也希望大家多多支持服务器之家。
原文链接:https://blog.csdn.net/scropio0zry/article/details/89239897