Difference between HasOne and BelongsTo in Sequelize ORM - node.js

Question

I am developing a sails.js app with sequelize ORM. I am a little confused as to when BelongsTo and HasOne need to be used.
The documentation states that :
BelongsTo associations are associations where the foreign key for the
one-to-one relation exists on the source model.
HasOne associations are associations where the foreign key for the
one-to-one relation exists on the target model.
Is there any other difference apart from the the place where these are specified? Does the behavior still continue to be the same in either cases?

Answer 1

This is more universal problem.
The main difference is in semantic. you have to decide what is the relationship (Some silly example):
Man has only one right arm. Right arm belongs to one man.
Saying it inversely looks a little weird:
Right arm has a man. A man belongs to right arm.
You can have man without right arm. But alone right arm is useless.
In sequelize if RightArm and Man are models, it may looks like:
Man.hasOne(RightArm); // ManId in RigthArm
RightArm.belongsTo(Man); // ManId in RigthArm
And as you notice there is also difference in db table structure:
BelongsTo will add the foreignKey on the source where hasOne will add on the target (Sequelize creates new column 'ManId' in table 'RightArm' , but doesn't create 'RightArmId' column in 'Man' table).
I don't see any more differences.

Answer 2

I agree with Krzysztof Sztompka about the difference between:
Man.hasOne(RightArm);
RightArm.belongsTo(Man);
I'd like to answer Yangjun Wang's question:
So in this case, should I use either Man.hasOne(RightArm); or
RightArm.belongsTo(Man);? Or use them both?
It is true that the Man.hasOne(RightArm); relation and the RightArm.belongsTo(Man); one do the same thing - each of these relations will add the foreign key manId to the RightArm table.
From the perspective of the physical database layer, these methods do the same thing, and it makes no difference for our database which exact method we will use.
So, what's the difference? The main difference lays on the ORM's layer (in our case it is Sequalize ORM, but the logic below applies to Laravel's Eloquent ORM or even to Ruby's Active Record ORM).
Using the Man.hasOne(RightArm); relation, we will be able to populate the man's RightArm using the Man model. If this is enough for our application, we can stop with it and do not add the RightArm.belongsTo(Man); relation to the RightArm model.
But what if we need to get the RightArm's owner? We won't be able to do this using the RightArm model without defining the RightArm.belongsTo(Man); relation on the RightArm model.
One more example will be the User and the Phone models. Defining the User.hasOne(Phone) relation, we will be able to populate our User's Phone. Without defining the Phone.belongsTo(User) relation, we won't be able to populate our Phone's owner (e.g. our User). If we define the Phone.belongsTo(User) relation, we will be able to get our Phone's owner.
So, here we have the main difference: if we want to be able to populate data from both models, we need to define the relations (hasOne and belongsTo) on both of them. If it is enough for us to get only, for example, User's Phone, but not Phone's User, we can define only User.hasOne(Phone) relation on the User model.
The logic above applies to all the ORMs that have hasOne and belongsTo relations.
I hope this clarifies your understanding.

Answer 3

I know this is a 4-years late answer, but I've been thinking of it, searching the docs, and googling since yesterday. And couldn't find an answer that convinced me about what was happening. Today I've got to a conclusion: the difference is not just a matter of semantics, definitely!
Let's suppose you have the following statement (from the docs):
Project.hasMany(Task);
It creates, in Project model, some utility methods on the instances of Project, like: addTask, setTask etc. So you could do something like:
const project = await Project.create({...});
// Here, addTask exists in project instance as a
// consequence of Project.hasMany(Task); statement
project.addTasks([task1, task2]);
Also, in the database, a foreign key in tasks relation would've been created, pointing to projects relation.
Now if, instead of Project.hasMany(Task);, I had stated only:
Task.belongsTo(Project);
Then, similarly, in the database, foreign keys in tasks relation would've been created, pointing to projects relation. But there wouldn't be any addTasks method on project instances though. But, by doing Task.belongsTo(Project);, Sequelize would create a different set of methods, but only on task instances this time. After doing that, you could associate a task to a project using, for example:
const proj = await Project.findByPk(...);
const task1 = await Task.create({...});
...
// Here, setProject exists in task instance as a
// consequence of Task.belongsTo(Project); statement
task1.setProject(proj);
The docs defines as source, the model that owns the method used to create the association. So, in:
Project.hasMany(Task);: In this statement, Project is the source model. Task is, in turn, the target model.
Task.belongsTo(Project);: In this statement, Task is the source model. Project is, in turn, the target model.
The thing is that, when creating associations using hasOne, hasMany, belongsTo, and belongsToMany, the instances utility methods are created only on the source model. In summary: if you want to have the utility methods created both in Project and Task instances, you must use the two statements for describing the same the association. In the database itself, both will have the same redundant effect (creating a foreign key on tasks relation pointing to projects relation's primary key):
// All the instances of Project model will have utility methods
Project.hasMany(Task);
// All the instances of Task model will have utility methods
Task.belongsTo(Project);
const project = await Project.create(...);
const task1 = await Task.create(...);
const task2 = await Task.create(...);
...
// as a consequence of Project.hasMany(Task), this can be done:
project.addTask(task1);
...
// as a consequence of Task.belongsTo(Project), this can be done:
task2.setProject(project);
BTW, after writing this answer, I realized that this is the same thing that Vladsyslav Turak is explaining in his answer, but I decided to keep my answer here because it adds some important practical information involving the utility methods stuff.

Answer 4

One-to-One belongTo or hasOne
Using the right arm example, and Sequelize's own documentation. The question we must ask is, can a man survive without a right arm? Or can a right arm survive without a man? To determine where we want our foreign key to exist is to answer this question. Let's take a more practical example.
Let's say you have a community website. Your users are all represented by a singular Profile model (or User model). But in a community you will also have administrators and moderators, both with their own sets of rights, and maybe even a different kind of profile. Instead of adding admin/mod specific fields to the User model, it might be best to create a separate model to represent an admin/mod.
Here's what basic user model looks like (ignoring constraints and validations):
class User extends Model {
static associate(models) {}
}
User.init(
{
username: DataTypes.STRING(25),
password: DataTypes.STRING(50)
}
)
Now here's a model that represents an admin or mod, which is intended to extend the user model:
class Staff extends Model {
static associate(models) {}
{
Staff.init(
{
permissions: DataTypes.ARRAY(DataTypes.STRING),
roleType: DataTypes.STRING(20),
}
)
So we ask our selves, can a user exist without admin/mod? Can an admin/mod exist without a user? A user doesn't have to be staff to use your services, but an admin/mod still needs a username and password in order to login. You could add those fields to the Staff model, but the truth is, it would be repeating information and make things harder to keep track of.
At the heart, an admin/mod would have the same attributes as a normal user, just with special abilities. If you intend otherwise, I'd still maintain a BaseUser model to organize and keep what each model has in common together. An admin/mod account would still have a username and password, and likely an email as well. Otherwise, you'd end up having two users with the same info, and in a community that can be confusing, and difficult to manage.
It is determined that a user does not need a Staff object associated with it to exist, so we shouldn't put the foreign key on the user profile. This still doesn't quite answer our question though. Remember, hasOne() puts the FK on the target model, while belongsTo() places the FK on the source. So we could say that Staff.belongsTo(User) or User.hasOne(Staff) that meets the requirement of the FK has to exist on the Staff model.
Whether you put a belongsTo() on the Staff model, or a hasOne() on the User model is a matter of semantics, and doesn't really matter. Either will associate the Staff model with the User model, allowing you to perform the User.getStaff() method. If you want to be able to get user account from a Staff instance, you could add a reference column without creating an actual association like so on our Staff model (this doesn't add constraints or associations, merely as it implies, a reference):
user: {
type: DataTypes.INTEGER,
references: {
model: User,
key: 'userId'
}
}
I hope this helps.