Sequelize-typescript: Specifying a `field` in the @Column decorator does not map back to the decorated name.

[aventurella]

For example:

@Column({field: 'search_name', type: DataType.STRING })
searchName: string;

When querying on this model only search_name is returned and searchName is undefined on the model.

[aventurella]

This seems to work to map the names back to the @Column defined names

let modelAttributes = (<any>MyModel).attributes;
queryResult.forEach(row => {
    for(let key in modelAttributes){
        let column = modelAttributes[key];

        if((<any>row).dataValues[column.field] !== undefined){
            row[column.fieldName] = (<any>row).dataValues[column.field];
        }
    }
})

Now myRow.toJSON() still does the wrong thing, it returns the field name not the @Column name. but that could also be solved with 1 override of toJSON to look at the class's attributes again.

now there is a performance cost here per model, especially if the result set is some huge number, so it might also be worth considering making the user explicitly call the transform and just documenting it appropriately.

Something like this:

export function toJSON<T>(cls: { new(...args: any[]): any; }, model: T): any{
    let attrs = (<any>cls).attributes;
    let result = {}

    for(let key in attrs){

        let column = attrs[key];
        let fieldName = column.fieldName;

        if((<any>model).dataValues[column.field] !== undefined){
            result[fieldName] = (<any>model).dataValues[column.field];
        }
    }

    return result;
}

[RobinBuschmann]

Hey @aventurella Thanks for reporting. Can you provide a more advanced example or much better a repository which shows the issue? Which version are you using? I cannot reproduce it - for me it is working very well.

[aventurella]

You know what I think it is... In my particular model, I have 2 blob fields that host a JPG. So when I query for list views etc, I need to omit those 2 blob fields so I query only specific attributes:

MyModel
.findAll<MyModel>({
    order: [ ['created_at', 'DESC'] ],
    // omits columns `blob_1` and `blob_2`
    attributes: ['id', 'created_at', 'name', 'another_column_2', 'another_column_1']
})

Each of these attributes is defined on the model as:

@Column({field: name})
name: string

@Column({field: another_column_2})
anotherColumn1: string

@Column({field: another_column_1})
anotherColumn2: string

@Column({field: blob_1})
blob1: string

@Column({field: blob_2})
blob2: string

My guess is when that is the query path via attributes that the remapping doesn't happen.

We could say: well just don't use field, or here's some docs that explain what you get when you override field. That could be enough. The use case seems relevant as the user may not own the table that they are querying into aka: Sequelize may not have been responsible for creating it so the column names are whatever they are. Pair that with JavaScript namingConventions and you get the mismatch pretty easily.

So it becomes: should my JavaScript code useTheCommonConvention all over EXCEPT with certain models or should I try to normalize it.

[RobinBuschmann]

Are you using the name of the properties or the name of the fields in the attributes array?

[aventurella]

When I use the names of the properties, it fails to query. aka, if I use anotherColumn1 in the query attributes I get a SQL error that the column does not exist. So I have to use another_column_1 in the query attributes

[aventurella]

Side note, this lib is really great, thanks for putting in the time to write/maintain/deal with random people posting issues =)

[RobinBuschmann]

Hey thank you very much.

Normally you should use the property name. Which sequelize and which sequelize-typescript version are you using?

With sequelize-typescript 0.4.0 and sequelize 4.3.2 it is working as expected. So unfortunately I can't reproduce it..

[aventurella]

Ah.. i'm using 0.3.5 and 4.0.0.. I'll bump! thanks!

[aventurella]

Yup! looks like it's not an issue in 0.4.0.. THANKS!!!!

[RobinBuschmann]

Did you updated sequelize as well? So could it be that the issue was caused by sequelize?