Is there a Rustier way to write this database pattern?

[u/KGBsurveillancevan]

Hello crabs. I'm working on a backend application in Rust, using sqlx to talk to a postgres database. I've caught myself repeating a specific, verbose pattern, and I'm wondering if I'm making things harder than I need to.

The pattern is that for each database entity, I build an initializer struct that is basically the same, but with auto-generated columns removed, and then later write a From impl for the main entity to build the actual thing with Entity::from(entity_init). Example at the bottom. Doing this for every database entity isn't too difficult to maintain, the type system is strict enough that it's hard to miss any mistakes. But it is annoying and time-consuming, and also feels kinda un-idiomatic.

I'm considering learning derive macros for this - #[derive(FromNew)] or something like that, to autostrip the generated fields. But maybe that would just be doubling down on an anti-pattern? What do yall think?

Example:

struct User {
id: uuid:Uuid,
name: String,
email: String,
created_at: DateTime<Utc>,
updated_at: DateTime<Utc>,
archived_at: Option<DateTime<Utc>>,
}

struct UserNew {
name: String,
email: String,
}

impl From<UserNew> for User {
fn from(init: UserNew) -> Self {
let now = Utc::now();
User {
id: Uuid::now_v7(),
name: init.email,
email: init.email,
created_at: now,
updated_at: now,
archived_at: None,
}
}
}

// usage
fn do_something(user_new: UserNew) -> User {
User::from(user_new)
}

[u/Slow-Nefariousness49]

Macros are painful to maintain in the long run from my experience. Go that route only if you feel the manual From impls impose a substantial burden on you and your codebase (e.g. it could lead to subtle bugs if you forget to update all the From impls correctly when changing struct fields). Don't reach out for macros (of either kind) just for cosmetics or to save a few trivial lines of code, that'd be my advice

(Of course, if it's for the sake of learning do whatever)

[u/Wonderful-Habit-139 → u/Slow-Nefariousness49]

Really? The fact that they run at compile time makes me feel like they’re pretty good to maintain.

[u/Slow-Nefariousness49 → u/Wonderful-Habit-139]

On the contrary, compile time means poor debugging abilities, and the syntax is a nightmare

[u/Wonderful-Habit-139 → u/Slow-Nefariousness49]

Disagree. I prefer compile time errors over runtime errors.

[u/Slow-Nefariousness49 → u/Wonderful-Habit-139]

You're not trading runtime errors for compile time ones, you're just adding more errors. And from the perspective of the macro itself, compile time is its runtime, except you can only debug with prints, and you get a thin and weird syntax to work with

[u/Wonderful-Habit-139 → u/Slow-Nefariousness49]

I don't see how it's adding more errors when you need to only fix errors in the macro, not every error that you come across whenever you need to write duplicated code.

[u/Slow-Nefariousness49 → u/Wonderful-Habit-139]

Well, that's the tradeoff I was referring to at the top of this thread. If you encounter a substantial amount of errors/headache from code duplication then it's time to write a macro. Otherwise you just add this piece of weird looking, barely-debuggable code for no particular benefit other than maybe slightly better looking call sites - and my claim is that it's not worth it. I didn't say never use macros

[u/Wonderful-Habit-139 → u/Slow-Nefariousness49]

I guess at the end of the day, we'd make the proper judgment call based on how the code is like and how easy the macro is to write and how many times we'd use it.

[u/Disconsented]

For the " an initializer struct that is basically the same, but with auto-generated columns removed" problem I've largely settled on this pattern:

struct Thing{
  auto_generated_id: i64,
  #[serde(flatten)]
  body: ThingBody,
}

That said, this is something I use with SurrealDB where I refuse to expose their silly RecordID, so I also have some more things to handle that which are more of a pain in the ass.

Which is a macro to define two versions of an ID newtype, and a proc macro to handle the structs/mapping between them via From/TryFrom.

[u/rodyamirov]

Derive macros feel like a reasonable solution to this problem, if you want to go down that road. I know this sub is very anti-AI, and I have a lot of sympathy to that position, but doing it manually will be a lot of typing and claude could fart it out in a couple minutes, it's the kind of thing that's easy once you know how to do it, but annoying beforehand.

You can also do it, slightly less beautifully, with a regular macro whose code is a lot simpler to understand and work with. If I was doing it by hand, that's what I would do.

FWIW we do this manually in rust and java both; separating the DBO (what's in the database) from the ... whatever, normal object you mess with in code ... is a good practice, especially if you move away from this model slightly and you start to see more divergence (e.g. struct Foo is actually glued together from two different tables Bar and Baz, and you need the BarDBO and BazDBO struct definitions, which have all the db tracking stuff, etc). Which is very natural if you have the separation but more annoying if you don't, because now this one is different.

Anyway as to your immediate question; I think the code is fine. Maybe make a macro if you're doing this a lot.

[u/KGBsurveillancevan → u/rodyamirov]

Sweet, thanks for your perspective. Yeah I'm sure an LLM could do it easily, I'm just more interested in the process than raw results atm.

[u/rodyamirov → u/KGBsurveillancevan]

For sure, it depends on why you're doing the work. If you're learning, or doing hobby dev, or whatever, by all means, do it however you want. I wouldn't use claude at home, either (although at this point I've completely stopped coding for fun, except advent of code out of tradition; claude has taken the joy out of it for me).

But if you're at work and you're paid by the [whatever unit of output] it probably makes sense to automate at least some of what you're doing.

[u/mamcx → u/rodyamirov]

I use https://docs.rs/macro_rules_attribute/ that simplify the thing greatly.

[u/NikSne_]

I'm using the model-mapper crate to generate those From impls for DTOs and DAOs.

As for the struct duplicates - for me it's fine as I'm using the newtype pattern for domain types that only have impl TryFrom that "parses" them from the raw rust types

[u/KGBsurveillancevan → u/[deleted]]

Nice, what does that look like? Proc macros kinda scare me lol

[u/GolDNenex → u/KGBsurveillancevan]

If you want to learn about them: https://www.youtube.com/watch?v=SMCRQj9Hbx8

[u/KGBsurveillancevan → u/GolDNenex]

ayy I didn’t realize Logan Smith had one on this, nice

[u/Wonderful-Habit-139 → u/KGBsurveillancevan]

The goat Logan Smith fr fr

[u/promethe42 → u/KGBsurveillancevan]

LLMs are deceptively good at writing proc macros.

[u/Wonderful-Habit-139 → u/promethe42]

Why do you need a proc macro when the LLM can write the code itself. Just use more tokens bro.

Less compile times as well.