Grokking Diesel, Rust's ORM

https://medium.com/@Buys/grokking-diesel-652cb8886a63

by fanf2 • 9 years ago

162 53 9 years ago

Diesel's authors have been hard at work on docs, but there's only so many hours in the day. Love to see posts like this.

Scarbutt3• 9 years ago

I would have though that ORM's were an antipattern in Rust.

fredsir• 9 years ago

How come?

Scarbutt3• 9 years ago

Maybe because of the language constructs that facilitate functional programming, you would think a data driven centric approach would be chose first over objects.

swah• 9 years ago

Me too as in Golang...

dvdplm• 9 years ago

Is the column limit still a problem for Diesel? The 16 columns max default is not enough and even the optional 26/52 can be too little for some odd legacy schemas. I'm curious: is this a limitation that will be overcome as the library matures or is it intrinsic to the codegen architecture?

killercup2• 9 years ago

It's currently dependent on implementing traits for very large tuples, so you could argue it's a language feature we are waiting for (cf. open RFC #1935 [1]). (There was a PR on Diesel to use HLists but it's no longer pursuit.)

[1] https://github.com/rust-lang/rfcs/pull/1935

neverminder4• 9 years ago

What was the reason you guys dropped HList approach? I'm curious since I have to deal with tables with north of 200 hundred columns and because of forever annoying Scala's tuple parity limit (22) Slick falls back to HList which is really heavy on a compiler and IDE aside from other drawbacks.

rabidferret9• 9 years ago

It'll eventually go away when some form of variadic generics lands in the language

rabidferret9• 9 years ago

If you open an issue we can up the limit again

neverminder4• 9 years ago

I wish it was closer to Scala's Slick which is an FRM (Functional Relational Mapping), since Rust's syntax is so similar to Scala. Unlike ORMs, libraries like Slick or JOOQ (Java) have pretty much 1 to 1 DSL to SQL and Slick also provides compile time type safety which in my opinion is the main point of using it.

steveklabnik11• 9 years ago

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.

neverminder4• 9 years ago

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.

throwaway91111• 9 years ago

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.

virtualwhys2• 9 years ago

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.

squiguy7• 9 years ago

The nice thing about diesel is that it does provide compile time safety as well. Not sure if you alluded to that, but even though it doesn't have the FRM style it still offers that benefit of compile time checking. I personally like having code generation handle the boilerplate of making something queryable or insertable.

kbenson3• 9 years ago

The last major component, and ‘secret weapon’ or ‘unofficial guide’ (according to me) is the the test suite in the official repo (https://github.com/diesel-rs/diesel/tree/master/diesel_tests).

The tests are indeed informative, and give a good idea of how it would be used in practice. I just looked at a few and I have a much better idea of how Diesel looks to be used in practice.

What I didn't see, and don't know if it exists since I haven't read a lot of the docs, is whether Diesel has a built in way to deliver joined results as HashMaps with all fields, as that would be the simplest way I would use it in practice.

For example, if I'm doing the equivalent of:

    SELECT user.*, post.*, comment.* FROM user LEFT JOIN post ON user.id = post.user_id LEFT JOIN comment ON post.id = comment.post_id

Does it have a helper method to identify the three tables that are joined, and instead of returning individual rows, return a HashMap of the user_id to user, a HashMap of the user_id to a list of posts, and a HashMap of the post_id to a list of comments? I think that would be:

    vec![ HashMap<i32,User>, HashMap<i32,Vec<Post>>, HashMap<i32,Vec<Comment>> ]

This would approximate the actual "objectiness" or many ORMs, and would make it easier to loop over data in the desired way with a minimum of boilerplate.

Edit: Or perhaps the more performant way would be to allow registering of callbacks for each change of user, post and comment, and call the appropriate one if defined. That way there isn't time and memory spent on condensing the data into hashmaps? I'm new to thinking about how to deal with ORM results in a language like this.

pedrocr• 9 years ago

Isn't what you actually want from that something like one of the following?

    HashMap<User, (Vec<Post>, Vec<Comment>)>
    HashMap<i32, (User, Vec<Post>, Vec<Comment>)> 
    Vec<(User, Vec<Post>, Vec<Comment>)>

kbenson3• 9 years ago

I think Comments are children of Posts, so ideally there would be a way to easily access all comments by post_id. Ideally, comments would be keyed to their post, and the post would be keyed to the user.

On rethinking this though, I'm wondering if the more performant way might be to provide a helper function that iterates over all returned rows, identifies when one record type in the result ends and another begins (the same steps you have to do to condense), but just executes a registered callback at that time. E.g. user_begin, user_end, post_begin, post_end, etc.

Although I should probably read up more on how Java/C/C# do this before spouting my half formed ideas about an area I'm not really informed in.... ;)

rabidferret9• 9 years ago

Not a HashMap specifically, but there is a way to group them into `Vec<(User, Vec<(Post, Vec<Comment>)>)>`. (Which you can convert into a hashmap pretty easily) http://docs.diesel.rs/diesel/associations/index.html for details.

kbenson3• 9 years ago

That's actually what I was looking for. I'm was too out of practice in general with signatures in static languages and unfamiliar with Rust's syntax in specific to figure it out and express what I was looking for correctly. ;)

kiliankoe• 9 years ago

Completely unrelated to the topic, but does anybody know why I'm getting a private gist link with the post's content when sharing it from MobileSafari (iOS 11 Beta)?

endymi0n• 9 years ago

After the unfortunate news from NPM today, I'm hoping Diesel doesn't come with a built-in defeat device... /s

Grokking Diesel, Rust's ORM

Related Stories