Typechecking SQL in Slick and Doobie | Hacker News Reader

Typechecking SQL in Slick and Doobie

underscore.io

40 pointsd6y7 comments

This is great! I tend to avoid abstractions for SQL, but Slick < 3.0 made type marshalling really annoying for pure SQL queries...so much so that I ended up using the DSL and its boilerplate table definitions. I'm looking forward to using the tsql functionality.

On another note, I've never heard of Doobie, and that is as someone who has spent at least a few hours in the past few months researching better Scala-oriented database access libraries. Seems to have come out of nowhere.

Doobie is quite new, though it was available before Slick 3. If you're still in the market for a database access library I would definitely check it out. It's very simple but powerful.

The evolution of database access is interesting, from raw SQL, to ORMs, to tuple oriented abstractions over SQL (Slick, Squeryl in Scala), and now Doobie and Slick return to allowing raw SQL (with machinery in place to make it safer).

It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new ways to integrate these, I 'm curios to see how this paradigm will change.

I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to the programmer, would MV* become less practical?

Given network latency it seems dangerous to abstract out the client and server distinction.

As for MVC, I think there has been an ongoing shift away from it, or at least a refinement, for a long time. Functional programs looks quite different. React is a good example, emphasising unidirectional data flow rather than the cycles in MVC.

> I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to the programmer, would MV* become less practical?

GWT, basically?

There are a handful of Javascript frameworks taking this approach. The community has adopted the term "isomorphic javascript" to collectively describe them (i.e. "same code on the client and server").

See http://isomorphic.net for examples. However, note that they appear to be quite inclusive in their definition. For example, I'd definitely consider Meteor to be one of these frameworks, but React? Not so much.

Something similar is available in F# using FSharp.Data.SqlClient[0].

[0] http://fsprojects.github.io/FSharp.Data.SqlClient/

Reply on news.ycombinator.com