是否可以在普通的sql Slick中使用IN子句来表示整数?

时间:2015-07-01 08:46:24

标签: scala slick

这里有一个类似的问题,但实际上并没有回答这个问题。

Is it possible to use IN clause in plain sql Slick?

请注意,这实际上是一个更大更复杂的查询的一部分,所以我确实需要使用普通的sql而不是光滑的提升嵌入。像下面这样的东西会很好:

val ids = List(2,4,9)
sql"SELECT * FROM coffee WHERE id IN ($ids)"

3 个答案:

答案 0 :(得分:13)

sql前缀解锁StringContext,您可以在其中设置SQL参数。列表没有SQL参数,因此如果您不小心,可以轻松地在此处打开自己的SQL注入。关于在this question上使用SQLServer处理此问题,有一些好的(以及一些危险的)建议。您有几个选择:

您最好的选择可能是使用#$运算符和mkString来插入动态SQL:

val sql = sql"""SELECT * FROM coffee WHERE id IN (#${ids.mkString(",")})"""

这没有正确使用参数,因此可能会对SQL注入和其他问题持开放态度。

另一种选择是使用常规字符串插值和mkString来构建语句:

val query = s"""SELECT * FROM coffee WHERE id IN (${ids.mkString(",")})"""
StaticQuery.queryNA[Coffee](query)

这与使用#$的方法基本相同,但在一般情况下可能更灵活。

如果SQL注入漏洞是一个主要问题(例如,如果用户提供了ids的元素),则可以为ids的每个元素构建一个带有参数的查询。然后,您需要提供自定义SetParameter实例,以便光滑可以将List转换为参数:

implicit val setStringListParameter = new SetParameter[List[String]]{
    def apply(v1: List[String], v2: PositionedParameters): Unit = {
        v1.foreach(v2.setString)
    }
}

val idsInClause = List.fill(ids.length)("?").mkString("(", ",", ")")
val query = s"""SELECT * FROM coffee WHERE id IN ($idsInClause)"""
Q.query[List[String], String](query).apply(ids).list(s)

由于您的idsInts,这可能不太重要,但如果您更喜欢这种方法,则只需将setStringListParameter更改为使用{{1}而不是Int

答案 1 :(得分:4)

  val ids = List(610113193610210035L, 220702198208189710L)

  implicit object SetListLong extends SetParameter[List[Long]] {
    def apply(vList: List[Long], pp: PositionedParameters) {
      vList.foreach(pp.setLong)
    }
  }

  val select = sql"""
        select idnum from idnum_0
        where idnum in ($ids#${",?" * (ids.size - 1)})
    """.as[Long]

@Ben Reich是对的。 这是另一个示例代码,在光滑的3.1.0上进行测试。

($ids#${",?" * (ids.size - 1)})

答案 2 :(得分:1)

虽然这不是普遍的答案,可能不是作者想要的,但我仍然想向任何人提出这个问题。

某些数据库后端支持数组类型,并且Slick有扩展,允许在插值中设置这些数组类型。

例如,Postgres的语法为where column = any(array),而slick-pg可以使用以下语法:

def query(ids: Seq[Long]) = db.run(sql"select * from table where ids = any($ids)".as[Long])

这带来了一个更清晰的语法,它对语句编译器缓存更友好,也可以安全地避免SQL注入,并且使用#$var插值语法创建格式错误的SQL的总体风险。