Deriving Insertable for struct enums

[demhadais]

Backend

PostgreSQL, MySQL, SQLite

What do you want to add to diesel?

It would be awesome to be able to derive Insertable for struct enums. For example:

use diesel::prelude::*;

diesel::table! {
    menu_items(id) {
        id -> Integer,
        name -> Text,
        bread -> Nullable<Text>,
        meat -> Nullable<Text>,
        dressing -> Nullable<Text>,
    }
}

#[derive(Insertable)]
enum MenuItem {
    Sandwich { name: String, bread: String, meat: String },
    Salad { name: String, dressing: String },
}

Of course, you just could do this:

#[derive(Insertable)]
#[diesel(table_name = menu_items)]
struct Sandwich {
    name: String,
    bread: String,
    meat: String,
}

#[derive(Insertable)]
#[diesel(table_name = menu_items)]
struct Salad {
    name: String,
    dressing: String,
}

enum MenuItem {
    Salad(Salad),
    Sandwich(Sandwich),
}

#[derive(Insertable, Default)]
#[diesel(table_name = menu_items)]
struct GenericMenuItem {
    name: String,
    bread: Option<String>,
    meat: Option<String>,
    dressing: Option<String>,
}

impl Insertable<menu_items::table> for MenuItem {
    type Values = <GenericMenuItem as Insertable<menu_items::table>>::Values;

    fn values(self) -> Self::Values {
        let generic = match self {
            MenuItem::Salad(Salad { name, dressing }) => GenericMenuItem {
                name,
                dressing: Some(dressing),
                ..Default::default()
            },
            MenuItem::Sandwich(Sandwich { name, bread, meat }) => GenericMenuItem {
                name,
                bread: Some(bread),
                meat: Some(meat),
                ..Default::default()
            },
        };

        generic.values()
    }
}

This is a fair amount of boilerplate, especially as the numbers of fields and variants increase. It also means polluting the codebase with new structs (GenericMenuItem, Sandwich, and Salad could all be eliminated).

Implementation notes

On a high level, I think for enums like this:

enum MenuItem {
    Salad {
        name: String,
        dressing: String,
    },
    Sandwich {
        name: String,
        bread: String,
        meat: String,
    },
}

we could take the union of all the fields, and then the resulting values tuple would be equivalent to the output of GenericMenuItem::values above.

I doubt enums like the below could be supported with a derive, since the derive wouldn't have access to the underlying fields of Salad and Sandwich

enum MenuItem {
    Salad(Salad),
    Sandwich(Sandwich),
}

but supporting the first type would be a great improvement.

Additional details

No response

Checklist

• I have already looked over the issue tracker and the discussion forum for similar possible closed issues.

[weiznich]

Thanks for writing this proposal. I wonder how common this pattern is. At least in my experience you often have one insertable type for your tables. I would guess that this is the case for most other users as well.

Given that it's hard to say this additional complexity is something that we want to maintain in diesel.. On the other hand that seems like something that could be reasonably done by a macro outside of diesel, so maybe it's a better approach here to start with such a macro outside of diesel and if it turns out to be a common pattern we still can pull it back?

[demhadais]

Very fair, not sure how common the pattern is either. I'll probably try to whip something up and publish it if I get a chance. Thanks!