Hacker News Reader

Comment by steveklabnik | Hacker News Reader

Hm, Diesel is also trying to do the "1-1" thing and is certainly focused on compile-time type safety.

I haven't used Slick, I'd be interested, if you have the time, in an elaboration with examples on this stuff.

Well, like I said Slick is not an ORM whereas Diesel is. Slick is not as much about an ORM abstraction, but writing SQL queries in Scala by leveraging it's collections library, taking advantage of Scala's advanced features such as operator overloading, etc.

For instance this is an example from Diesel:

Post::belonging_to(user).load(&connection)

And this is how it would look like in Slick:

Post.filter(_.userID === 1).result

So both of the above would translate into SQL "SELECT * FROM posts WHERE user_id = 1", however Slick is more explicit whereas Diesel definitely feels like an ORM. The tripple equals in Slick example for instance is a nice touch and an example of operator overloading, because userID could be of type Integer or Option[Integer] (nullable field) and it would work both ways.

> like I said Slick is not an ORM whereas Diesel is.

I personally find "ORM" to be such a broad term as to be almost meaningless. This may be a personal problem :)

I see now. I am pretty sure that you could write

  posts.filter(user_id.eq(1)).load(&connection)

if you wanted; the belonging_to is just fancier and a bit shorter.

Anyway, thank you! I've mentally filed a "check out Slick sometime" bug for my infinite personal-to-do list :)

No problem, I guess what I'm trying to say is that just like Rust took inspiration from Scala syntax (at least I get this feeling), maybe so could Diesel from Slick.

Slick was definitely an influence on Diesel's design. I tried to have our query builder map more closely to SQL though, whereas Slick feels like it's trying to pretend it's just an Iterable.

You could just as easily write `posts.filter(user_id.eq(1)).load(&connection)`.

Just glanced through the article; biggest difference I'd say between the two libraries would be, one composes, the other doesn't.

    val base = for {
      ur <- UserRole
       u <- ur.user
       r <- ur.role
    } yield (ur, u, r)

    val withManager = for {
      (ur, u, r) <- base
              ts <- TeamStaff if u.id === ts.userId
    } yield (ur, u, r, ts)

    val teams = for {
      (_, _, _, ts) <- withManager
                 t  <- Team if t.id === ts.teamId
    } yield (ts, t)

You can slice and dice a schema however you like, building up queries from other queries, none of which are run until you execute them. Basically you get semantically the same query plans as you'd get writing plain sql, but it's all type checked, sql injection safe, and compiled (queries generally are generated at compile time, not run time).

Quill, another Scala FRM library, is worth checking out in this regard, as is Haskell's Esqueleto.

Can you elaborate on how Diesel doesn't compose in this way? Composition is one of the main goals of Diesel.

Didn't see anything in the article, assumed query composition wasn't possible. I don't see anything offhand in the Diesel docs, are there examples that illustrate composition along the lines of the above?

Until you do something to cause the query to be evaluated, it's a value like any other, and you can combine them together however you want.

Also check out Squeryl; it's virtually the same thing as slick with an alternative (imho much more straightforward) syntax.

I do agree that things like associations are an entirely new layer of abstraction.

Reply on news.ycombinator.com