> For anything other than trivial queries ScalaQuery/Slick generates very bad SQL
For Slick, yes, but for ScalaQuery 0.10, absolutely not.
All of my ScalaQuery generated SQL is semantically _exactly_ what I would have written by hand, and completely typesafe, with generated prepared statements to boot. This includes outer join based queries, subselects, and other operations that cause Slick to generate nightmare SQL (why I'm avoiding Slick until the library is stable on the performance front).
I love ScalaQuery, but Slick, TBD, they have a ways to go yet, the new Scala collections syntax with groupBy and sortBy is particularly hideous compared to ScalaQuery's SQL based groupBy and sortBy.
The Slick team will sort things out, hopefully sooner rather than later (for example, I'd love to have Slick 2.0's composable parameterized query snippet functionality, that alone is a huge boilerplate WIN).
For Slick, yes, but for ScalaQuery 0.10, absolutely not.
All of my ScalaQuery generated SQL is semantically _exactly_ what I would have written by hand, and completely typesafe, with generated prepared statements to boot. This includes outer join based queries, subselects, and other operations that cause Slick to generate nightmare SQL (why I'm avoiding Slick until the library is stable on the performance front).
I love ScalaQuery, but Slick, TBD, they have a ways to go yet, the new Scala collections syntax with groupBy and sortBy is particularly hideous compared to ScalaQuery's SQL based groupBy and sortBy.
The Slick team will sort things out, hopefully sooner rather than later (for example, I'd love to have Slick 2.0's composable parameterized query snippet functionality, that alone is a huge boilerplate WIN).