4 ms·

For anything other than trivial queries ScalaQuery/Slick generates very bad SQL. I'd like to use it but generating deeply nested sub-queries when simple joins w

For anything other than trivial queries ScalaQuery/Slick generates very bad SQL. I'd like to use it but generating deeply nested sub-queries when simple joins would suffice is totally unacceptable. The PostgreSQL query optimizer can fix them in the simple cases but the MySQL and Oracle optimizers can't and it causes performance to drop off a cliff. HaskellDB suffers from a similar problem.

virtualwhys 13y ago
> 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).