21
What are you working on this week? (May. 05, 2024) (programming.dev)
submitted 6 months ago by secana@programming.dev to c/rust@programming.dev
16 comments fedilink hide all child comments

Hi rustaceans! What are you working on this week? Did you discover something new, you want to share?

you are viewing a single comment's thread
view the rest of the comments
[-] nebeker@programming.dev 7 points 6 months ago

Just learning. I threw together a little CRUD API in Rocket the other day.

Now I’m playing around with Diesel. I don’t love the intermediate New types, coming from EF Core. Is that because Rust ~~~~doesn’t really have constructors?

[-] sugar_in_your_tea@sh.itjust.works 2 points 6 months ago

Can you give an example? Pretty much everything in Diesel is abstracted away through trait macros.

[-] nebeker@programming.dev 1 points 5 months ago* (last edited 5 months ago)

The insert on their Getting Started guide.

let new_post = NewPost { title, body };

diesel::insert_into(posts::table)
    .values(&new_post)
    .returning(Post::as_returning())
    .get_result(conn)
    .expect("Error saving new post")

Of course the other possibility is this guide is very low on abstractions.

[-] sugar_in_your_tea@sh.itjust.works 2 points 5 months ago

Ah, I see. So you're expecting to have one object for creation, updates, queries, etc.

I work with something like that at work (SQLAlchemy in Python), and I honestly prefer the Diesel design. I build an object for exactly what I need, so I'll have a handful of related types used for different purposes. In Python, we have a lot of "contains_eager" calls to ensure data isn't lazy loaded, and it really clutters up the code. With Diesel, that's not necessary because I just don't include data that I don't need for that operation. Then again, I'm not generally a fan of ORMs and prefer to write SQL, so that's where I'm coming from.

[-] nebeker@programming.dev 1 points 5 months ago

One of my main concerns with this is the potential for making a lot of separate calls to the DB for a complex data structure. Then again there are trade offs to any architecture.

[-] sugar_in_your_tea@sh.itjust.works 1 points 5 months ago* (last edited 5 months ago)

Isn't the reverse true? If you make separate models for each query, the ORM knows exactly what data you need, so it can fetch it all as once. If you use generic models, the ORM needs to guess, and many revert to lazy loading if it's not sure (i.e. lots of queries).

That's at least my experience with SQLAlchemy, we put a lot of effort in to reduce those extra calls because we're using complex, generalized structures.

this post was submitted on 05 May 2024
21 points (95.7% liked)

Rust

5931 readers
11 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
EdTheLegendary@programming.dev
kahnclusions@programming.dev
torcherist@programming.dev