25

The ScalaDoc of the functions has not been filled out.

I know that the methods are used for mimicking SQL's IN keyword (eg, SELECT * FROM table WHERE id IN VALUES(1, 42, 101) could be done with table.filter(_.id inSet Seq(1, 42, 101))). I don't know what this "bind" version is or how to choose which I should be using.

Mike
  • 797
  • 2
  • 9
  • 17
  • 23
    @BobDalgleish The Slick source code is pretty hostile to human life. – Rag May 12 '15 at 22:00
  • [case in point](https://github.com/slick/slick/blob/559c3ada405865e45a78a7b6a5429ce19275fa35/slick/src/main/scala/slick/lifted/ExtensionMethods.scala#L49) – Alex Jun 21 '18 at 14:28

1 Answers1

23

inSet is an unsafe version of inSetBind which generates a safe/escaped sql value based on passed in input. In your example where the value is manually set, the two types of bind are equally safe.

Normally with bound parameters you get a performance boost (via generated prepared statement), but not the case with collection values. See here for the details.

Community
  • 1
  • 1
virtualeyes
  • 11,147
  • 6
  • 56
  • 91
  • 3
    I didn't understand the difference. Can you pls explain. I tried with the queries in slick. Found out that if I use inSet(List(1,2,3)) the query s built as where id in (1,2,3). If I use inSetBind(List(1,2,3)), the query becomes id in (?,?,?). – Yadu Krishnan Jan 09 '15 at 13:03
  • @YaduKrishnan the latter is the placeholder syntax referred to above, each ? is replaced with safe/escaped value. – virtualeyes Jan 14 '15 at 07:12
  • 1
    what do u mean by "safe/escaped" values? can you pls give an example? – Yadu Krishnan Jan 14 '15 at 07:13
  • @YaduKrishnan lookup sql injection attack, jdbc prepared statements, etc. Bottom line just use Slick's bind methods to ensure you have safe, performant queries -- simple ;-) – virtualeyes Jan 14 '15 at 08:28