Documentation Recommendation: Exporting a types prelude
Opened this issue · 2 comments
I've come up with a clever design pattern that simplifies the dilemma of making accessible types within schema.rs
Instead of listing all import_types
within diesel.toml as mapping to individual crates, instead make a diesel_types module and then pub use everything that's needed.
An example:
Diesel.toml
# For documentation on how to configure this file,
# see diesel.rs/guides/configuring-diesel-cli
[print_schema]
file = "src/schema.rs"
import_types = ["crate::diesel_types::*"]
diesel_types.rs
pub use crate::data::{gender::Gender as Enum_users_gender, user::UserStatus as Enum_users_status};
pub use diesel::sql_types::*;
pub use diesel_full_text_search::TsVector as Tsvector;
users/gender.rs
use async_graphql::Enum;
use diesel_derive_enum::DbEnum;
use diesel_derives::SqlType;
use serde::{Deserialize, Serialize};
#[Enum]
#[derive(Serialize, Deserialize, DbEnum, SqlType, Debug)]
#[PgType = "enum_users_gender"]
pub enum Gender {
Male,
Female,
Other,
#[serde(rename = "Prefer not to say")]
Undisclosed,
}
The advantage of this design pattern is that it's easier to do aliases and that because you're guaranteed types will be used there won't be any compiler warnings. It's a simple way to import all enums, base types and to address the TsVector alias all in one.
This is nice but I think as content it is more appropriate for the main diesel
docs. This crate has no particular opinion on how to structure your application.
I've thought about this a bit more and actually it's the cleanest solution to the problem of auto-generated diesel types not matching up with mapping names. So I think I should mention it in the README