5 definitions for the one simple struct/table, is this standard? - Can we have a DRY alternative?

[SamuelMarks]

Extracting out a little bit of almost real-world code, I find I need 5 representations of the same thing to do the most basic of operations.

Namely:

0

/// Now I can use this in the Diesel DSL
use diesel::prelude::Queryable;
use diesel::Selectable;

#[derive(Queryable, Selectable, serde::Deserialize, serde::Serialize, PartialEq, Debug)]
#[diesel(table_name = crate::schema::profiles)]
#[diesel(check_for_backend(diesel::pg::Pg))]
#[diesel(belongs_to(rust_actix_diesel_auth_scaffold::models::user::User, foreign_key = username))]
pub struct Profile {
    pub alias: String,
    pub username: String,
    pub rank: String,
    pub coins: u32,
    pub profile_image_url: Option<String>,
    pub created_at: std::time::SystemTime,
}

1

/// At least this one is generated (schema.rs)
diesel::table! {
    profiles (alias) {
        #[max_length = 25]
        alias -> Varchar,
        #[max_length = 50]
        username -> Varchar,
        rank -> Text,
        coins -> Int4,
        #[max_length = 2048]
        profile_image_url -> Nullable<Varchar>,
        created_at -> Timestamp,
    }
}

2

--- And this one is needed for my migration in up.sql:
CREATE TABLE "profiles"
(
alias             VARCHAR(25) PRIMARY KEY,
username          VARCHAR(50)                NOT NULL REFERENCES users (username),
rank              TEXT                       NOT NULL DEFAULT 'beginner',
coins             INTEGER CHECK (coins >= 0) NOT NULL DEFAULT 0,
profile_image_url VARCHAR(2048),
created_at        TIMESTAMP                  NOT NULL DEFAULT current_timestamp
);
CREATE UNIQUE INDEX "profiles_alias_idx" ON profiles (alias, username);

3

/// Now I can do:
/// use crate::schema::profiles::dsl::*;
//  let profile = diesel::insert_into(profiles)
//         .values(&NewProfile { ... })
#[derive(diesel::prelude::Insertable)]
#[diesel(table_name = crate::schema::profiles)]
pub struct NewProfile<'a> {
    pub alias: &'a str,
    pub username: &'a str,
    pub rank: &'a str,
    pub coins: u32,
    pub profile_image_url: Option<&'a str>,
}

4

/// Now I can do `web::Json<NewProfileJ>` in actix-web
#[derive(serde::Deserialize, serde::Serialize)]
pub struct NewProfileJ {
    pub alias: String,
    pub username: String,
    pub rank: String,
    pub coins: u32,
    pub profile_image_url: Option<String>,
}

---

So that's 5 representations of the same thing. Sure, I've had some fun in SQL and been able to get very specific. But pretend I didn't, and just wanted some obvious defaults, that a deterministic algorithm could trivially infer (type map).

In Python I wrote a compile to translate SQLalchemy into plain old Python classes (and back again). In Rust I suppose macros is the hacky reflection alternative.

Anyway would be great to get your perspective here, as I'm sure I'm not the first to ask about this, and there must be solutions?

[weiznich]

I think you have a massive misunderstanding on how these types can and should play together. They might look similar in your case, but in practice they are different.
Let's just go through the different variants.

The first observation is that you can either generate 2 from 1 or vice versa. So, sure you can count them as two types but you don't need to write both.

Any other type is strictly speaking optional. It's up to you and your use-cases how you design and use these types. For complex applications it's advice to have three different types there as the field of these types tend to quickly diverge based on your needs. That is something that you likely observe as soon as your application grows for some while.

Anyway let's go through the other variants one by one.

Struct 0 might seems like a "model" struct that maps 1:1 to tables, but that's a false assumption. These structs map 1:1 to query results, which can and often do include fields from more than one table.

For struct 3 and 4 I personally do not see the point why you keep separate structs there, as nothing is stopping you to put the #[derive(Insertable)] on the struct 4 definition. In fact that's exactly the case for which this derive is designed for: Use it when you already have an existing struct due to other reasons (in this case #[derive(Deserialize)]), otherwise prefer the tuple insert variant. That's something that explicitly called out the in relevant guide.

This leaves us with 3 out of those 5 types that you need to write: Struct 0, the SQL in 2 and struct 4. Now take a step back and look why this is the case:

• The SQL in 2 defines your database structure, it's clearly necessary to do that
• The struct 0 defines one possible way to represent "something" that's loaded from the database. In this case: Yes it 1:1 to your table, but that's a special case that won't be true in complex applications.
• Struct 4 defines the input for your insert. It exists anyway for external reasons and it needs to be separate from struct 0 as it does not include all fields, which is again an external requirement there. If that wouldn't be the case you could use the same struct 0 here as well.

So in the end it's all about flexibility: Instead of having a strict restrictive 1 table maps to 1 struct model diesel allows you to mix and match structs as required. That gives you the ability to only load/insert what you really need to load and insert, which makes your applications more performant and easier to maintain in the long run. The disadvantage is that you as an author are responsible for describing what you want.

But pretend I didn't, and just wanted some obvious defaults, that a deterministic algorithm could trivially infer (type map).

Sure the easy case might seem obvious, but that becomes complicated really quickly. For example: Which type to choose for the timestamp? std::time::Instant or chrono::NaiveDateTime or better the type from the time crate? Or do you want to exclude some field for whatever reason? Or just have an aggregate in there?
That said: It's certainly possible to write such a generator for the simple case and there are such generators out there on crates.io (and linked from the diesel.rs homepage). It's just out of scope for diesel as we optimize for the complex application case, not the "I can get something up quickly and run into problems later case". The later thing can be build on top of diesel.

Anyway would be great to get your perspective here, as I'm sure I'm not the first to ask about this, and there must be solutions?

This was discussed quite often in the issue tracker, so yes you would have been able to find an answer to that with rather minimal effort, eg by looking at this issue