

Typechecking SQL in Slick and Doobie - d6y
http://underscore.io/blog/posts/2015/05/28/typechecking-sql.html

======
saosebastiao
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.

~~~
noelwelsh
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).

------
bweitzman
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?

~~~
wlievens
> 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?

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

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

