Associations with changed-column names as foreign key

[ggrochow]

I am working on an application for use on an existing database, that uses mostly camelCased names instead of snake_cased. I would obviously like to unify the naming to be all snake_cased for use in rust, which I can do using #[column_name(...)], however combined with foreign_key its causing me some issues with associations.

This gist contains a working version of my code, that compiles and prints out what I expect it to. Custom schema derives since I have some columns named type

If you look at line 59 of main you can see im using companyId instead of the more rust-like company_id
Attempting to remedy this is where my error occurs.

changing it to

#[column_name(companyId)]
company_id: i64,

produces this error:

error: no field `companyId` on type `&Administrator`
  --> src/main.rs:54:1
   |
54 | #[derive (Debug, Queryable, Identifiable, Associations)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: this error originates in a macro outside of the current crate

Makes sense, since I've removed that, so I update the belongs_to of Administrator to be
#[belongs_to(Company, foreign_key="company_id")] to reflect the new-name.

Buuuuut now it produces a large error-pile complaining about full error gist here

error: no associated item named `belonging_to` found for type `Administrator` in the current scope
   = note: the method `belonging_to` exists but the following trait bounds were not satisfied: 
        `Administrator : diesel::associations::BelongsTo<_>`, ..., ... 

Using the following versions
rustc 1.16.0 (30cf806ef 2017-03-10)
diesel/diesel_codegen - version 0.12.0, with mysql

Is this a bug? or am I just attempting to accomplish this in the incorrect way?

Also does there exist some sort of page/repository of these not super helpful compiler errors, that will help me understand them a little better? or anything I should dig into for trying to figure it out on my own. Would a better understanding of the derive / proc macro system help? or are these just errors as confusing to others as well?

[sgrif]

I can confirm that this issue is still present. Given this struct:

struct Foo {
    #[column_name(barId)]
    bar_id: i32,
}

There is no way to define #[belongs_to(Bar)]. If you don't specify the foreign key, or explicitly specify foreign_key = "bar_id", the macro (surprisingly) does not error, but generates no code. If you specify foreign_key = "barId", the macro will complain that field doesn't exist.

We need to change the derive to:

• Not assume the field name and column name are the same
• Decide whether foreign_key = specifies the field name or column name (probably field name IMO)

[mann-ed]

Has there been any updates on this? I just ran into the same issue.

[kyryl-perepelytsia]

Hi guys, do we have any updates on it ? Or maybe some one found good workaround for it ?

[kyryl-perepelytsia]

For me worked:
use #[column_name={parent_id_from_schema}] before modified field on model and set #[belongs_to({parent_model}, foreign_key = "{parent_id_from_schema}")]

[tumluliu]

For me worked: use #[column_name={parent_id_from_schema}] before modified field on model and set #[belongs_to({parent_model}, foreign_key = "{parent_id_from_schema}")]

without the double quotes around {parent_id_from_schema}, it worked for me. I.e.:

#[diesel(belongs_to(PARENT_STRUCT_NAME, foreign_key = FIELD_NAME))]

see the doc