Reputation: 3366
I'm in the process of migrating to Slick 2.0.0-RC1 (from 1.x), and I'm having trouble getting IntelliJ to recognize the lifted embedding implicits around the TableQuery
statements. However, everything does compile, in both IntelliJ and sbt (read: play). I started by leveraging the new code generation feature, and just now I grabbed snippets from slick-examples verbatim — both produce the same behavior.
Using the first example of lifted embedding (https://github.com/slick/slick-examples/blob/master/src/main/scala/com/typesafe/slick/examples/lifted/FirstExample.scala) the following two things occur:
The line:
def supplier = foreignKey("SUP_FK", supID, suppliers)(_.id)
Produces an error on suppliers
saying Type mismatch, expected: TableQuery[NotInferredTT], actual: ((Tag) => FirstExample.Suppliers) => TableQuery[FirstExample.Suppliers]
The TableQuery[...]
vals (e.g., coffees) don't have any of the lifted collection-like operations on them (e.g., filter, map, take, etc.).
Weirdly enough, using for-comprehensions doesn't produce any errors, however nothing has the right type information (ends up as an Any
).
I'm positive that I've got the .simple._
import (it doesn't compile elsewhere without it). I've cleared all my caches, rerun my gen-idea, done full rebuilds, etc. with no progress. I'm running IntelliJ 12.1.6 Ultimate with the Scala 0.22.302 plugin. My own project uses SQLServer, but I tried the example with H2 and experienced the same thing.
Can someone point me in the right direction?
Upvotes: 0
Views: 1142
Reputation: 1
I think this is just suppressing the error but calling it directly in the function worked for me:
foreignKey("SUP_FK", supID, TableQuery[Suppliers])
Upvotes: 0
Reputation: 3366
I found a hack to get around this, but I'm really looking for something more robust. If I override SourceCodeGenerator
, and then override the TableDef
inside that, and then override the TableValueDef
inside that, I can override the def code
inside that to this:
override def code = s"lazy val $name = TableQuery[${TableClass.name}](tag => new ${TableClass.name}(tag))"
...and then I don't have problems with the macro not evaluating. It goes without saying that this isn't an ideal solution.
Upvotes: 0