Anorm VS Slick

For database access Anorm https://github.com/playframework/anorm

The Scala ecosystem has a few ways to do composable type-safe query building, e.g. Slick[0] or more recently Quill[1]. . I believe both also have ways to do compile-time string interpolation (e.g. sql"""select * from users where id = ${user.id}""") which generate prepared statements (I know Slick does prepared statements. Quill has similar macros but I haven't looked into how safe they are to use).

[0] https://scala-slick.org/

With all this in mind, I landed at the first candidate: slick from https://scala-slick.org/ that you all probably know.

I think Slick's current priority is also getting in Scala 3 support: https://github.com/slick/slick/issues/2177

Future releases might not be announced here. To get notified, go to https://github.com/slick/slick, click the Watch dropdown button at the top, select Custom, check Releases, and click Apply.

https://github.com/slick/slick/pull/2097 now I use slightly lower version of slick so this might be an upgrade that resolves (I do recall using it in 21 and it was still buggy and I filed a ticket, which I cannot find at the moment), but given a complex enough query (we have one in PROD which has tons of flexibility in terms of filters that can be passed in) but it also makes for complex code.

I started writing a reply but then I realized it would be long and depends on exactly what you mean, so maybe it's better to post the question in https://github.com/slick/slick/discussions/categories/questions?

You can see the draft release notes here and the upgrade guide at https://scala-slick.org/doc/prerelease/upgrade.html#upgrade-from-3-3-x-to-3-4-0. The latest docs are at https://scala-slick.org/doc/prerelease/index.html.

I purchased the very entertaining book Seven Languages in Seven Weeks. Although I found Haskell fascinating and tempting, I knew it was unrealistic to introduce it in our company. Scala on the other hand looked like it could be the holy grail: All the characteristics I was looking for, no need to abandon the JVM and its cornucopia of tools and libraries, and the possibility for coexistence with Java and therefore incremental adoption. After implementing some simple programs to identify any immediate risks of committing to the language and its ecosystem, I started to introduce Scala in customer projects. Luckily, I was fortunate enough to work with open-minded, curious, and ambitious team members who were also experienced enough to appreciate the benefits of the language. We immediately applied our experience with functional programming, and embraced immutability. Libraries like Slick and Akka HTTP (we actually started out with its predecessor, Spray) made building database-backed REST services a breeze. And the resulting code was robust and highly maintainable. Scala's expressive type system and type inference made it easy to build a restrictive, consistent domain model without bloating the code. There was virtually no overhead. Any boilerplate could be easily abstracted out. In the end, the application code felt natural, concise and elegant. Programming was fun again.

Slick is community-maintained these days. It appears likely this PR adding Scala 3 support will cross the finish line before too much longer: https://github.com/slick/slick/pull/2187

The two major SQL libraries in the Scala ecosystem these days are Doobie (https://tpolecat.github.io/doobie/) and Slick (https://scala-slick.org/).

With Doobie you manually write your queries, and then map the results into the objects in your domain model. Nothing is generated for you. OTOH, nothing is hidden and you are free to write queries as optimized and specialized as you need. The real selling point of Doobie is a typesafe API for manipulating and combining queries, and fragments of queries, into larger wholes. This works very well when your application interfaces with a database it doesn't own.

With Slick you get access to a DSL that lets you layout how your tables look. From there Slick offers an api that let's you treat SQL tables as-if they are basically mutable collections, with Slick handling all the SQL generation itself. You also get DDL, so that you can automate db creation and upgrades. This work very well when your application owns and controls the database it is connecting to.

Both of these have diverged from that traditional ORM model. Slick bills itself as FRM, or Functional Relational Mapping. And Doobie is embedded queries on steroids.