hasOne 'as' option produces wrong foreign key

[demosglok]

What are you doing?

i'm adding hasOne relationship with {as: ''} option, which leads to foreignKey in target table to be derived from alias name. Though same example is in docs, that is not what i'm expecting

models.User.hasOne(models.Device, {as: 'Calculator'})

which leads to query SELECT .. LEFT OUTEER JOIN Devices As Calculator ON User.id = Calculator.CalculatorId instead of Calculator.userId

To Reproduce
Steps to reproduce the behavior:

1. Define models X, Y
2. Set association 'hasOne' with alias: X.hasOne(Y, {as: 'Z'})
3. See error in query, Z.ZId instead of Z.XId

What do you expect to happen?

I want foreign key on target table to be left untouched and derived from source table

What is actually happening?

foreign key is derived from alias instead of source table name

Environment

Dialect:

• mysql
• postgres
• [*] sqlite
• mssql
• any
  Sequelize version: 5.7.3
  Node Version: 10.x
  OS: windows 10

[2kindsofcs]

the same thing happens when using mysql, too.

By the way, according to the doc, it says

hasOne method creates an association between this (the source) and the provided target.

and the description of options.as says

The alias of this model, in singular form.

as the doc says that this means the source, if there is an 'as' option then it seems normal to get aliasId rather than sourceId. I think it's just workig as same as the document implies.

@papb if there's an 'as' option when using hasOne method, the foreign key added to the target table should be sourceId ?

if it's not a bug, then I think it would be nice if the doc mentions about it more explicitly.
(I'm willing to make a pull request)

[papb]

@2kindsofcs Thanks for the post, I don't think this is a bug, OP should probably use Device.belongsTo(User, { as: 'Calculator' }) instead and it would probably work as they want.

About the docs improvement, I agree they need to be improved but leave it to me, I'm already working on it so let's not duplicate work :)

[brianle1301]

@papb But that wouldn't add the mixin to the source model? (i.e you can't do user.getCalculator()?)

Edit: It is quite counter-intuitive if defining as adds a new foreign key to the target table when hasOne() is called. It might make sense for belongsTo() to do this, but not hasOne(). IMO it would be more consistent if specifying as doesn't introduce any new columns like hasMany()

For example:

User.hasMany(Subscription, { as: 'payments' });           // This only affects the mixins
User.hasOne(Developer, { as: 'dev' });          // This adds devId to Developer which is quite counter-intuitive

Subscription.belongsTo(User, { as: 'payer' });                // This would add payerId which to me makes sense 

I understood it would be a breaking change but it would be very nice to see this consistency :)