Support raw identifiers

[andrejohansson]

Hello, it´s me again! :-)

Is there any way to support raw identifiers?

It might be a corner case, but sometimetimes it´s necessary to use the notation if you have naming collisions.

table! {
    options (id) {
        id -> Int4,
        label -> Varchar,
        values -> Array<Text>,
        // a field called type must use raw identifier
        r#type -> crate::domain::option::model::OptionTypeEnumMapping,
    }
}

#[derive(DbEnum, Debug, Serialize, Clone, Copy, WundergraphValue, GraphQLEnum)]
#[sql_type = "OptionTypeEnumMapping"]
#[PgType = "optiontype_enum"]
pub enum OptionTypeEnum {
    Checkbox,
    // collisions, so using raw identifier
    r#Option,
    r#String,
    Number
}

// Danger, calling the whole stuct Option!
#[derive(Clone, Debug, Identifiable, Queryable, Associations, WundergraphEntity)]
#[table_name = "options"]
pub struct Option {
    pub id: i32,
    pub label: String,
    pub values: Vec<String>,
    // And using type as a field
    pub r#type: OptionTypeEnum,
}

This gives the error:

error: proc-macro derive panicked
  --> src\domain\option\model.rs:9:1
   |
9  | / table! {
10 | |     options (id) {
11 | |         id -> Int4,
12 | |         label -> Varchar,
...  |
15 | |     }
16 | | }
   | |_^
   |
   = help: message: `"_impl_query_id_for_r#type"` is not a valid identifier
   = note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

This example is exaggerated but I do think there are valid uses if you want to keep a clean naming structure someties.

Is this supported already? Am I posting this in the right repo or should I post to juniper/diesel instead?

[weiznich]

I do not think supporting raw identifiers is the right way here. The better way is to provide corresponding attributes to rename the fields, as this is useful in more situations and allows a finer control.

Let's look at the different cases:

• For diesel's table macro there is already the #[sql_name = "some_name"] attribute. So you could write your example table as

  table! {
  options (id) {
      id -> Int4,
      label -> Varchar,
      values -> Array<Text>,
      #[sql_name = "type"]
      tpe -> crate::domain::option::model::OptionTypeEnumMapping,
  }
  }

  See the corresponding documentation here

• For WundergraphDerive there is the #[column_name = "foo"] attribute that let's you specify the corresponding column name (that one that is used in the diesel table! macro, so tpe in this example. You can then set the corresponding graphql name via the #[wundergraph(graphql_name = "Foo")]. See the corresponding documentation here

• For the enum there is #[graphql(name = "CustomVariantName")] for setting a custom variant string for graphql. I think juniper uses the same attribute here, so this works for both, the WundergraphValue and the GraphQLEnum. I'm not sure how DbEnum handles this case, as I'm not using this crate. (I normally just implement FromSql/ToSql by myself.) Documentation for WundergraphValue and for GraphQLEnum