hasMany not working with valid models

I have two valid models, Customer and Order, defined in two separate modules.

Example code (omitted columns / options):

var Customer = require('./order');    

var Order = sequelize.define('order', attrs, opts);
Order.belongsTo(Customer, {foreignKey: 'local_customer_id', targetKey: 'id'});
module.exports = Order;

Imagine that Customer is the same, short of the Order.belongsTo(Customer, {foreignKey: 'local_customer_id', targetKey: 'id'}); being replaced with Customer.hasMany(Order, {foreignKey: 'id', targetKey: 'local_customer_id'});, and a require for var Order at the top instead of Customer.

The problem here is, when running the Customer.hasMany line, I get the error ‘hasMany called with something that’s not an instance of Sequelize.Model’. However, if I put both of the lines into the Order module, such as this:

Order.belongsTo(Customer, {foreignKey: 'local_customer_id', targetKey: 'id'});
Customer.hasMany(Order, {foreignKey: 'id', targetKey: 'local_customer_id'});

That works fine, and the relations work.

My question is, why is this happening? The sequelize models work exactly as is, so my definition of them is correct. And they’re both exported via a module.exports = Order-esque line, so they’re both exported correctly.

[alitaheri]

This has nothing to do with sequelize. You can read more about circular dependencies here. In other words, you must first define both Models, export them and THEN require one another and call these associative functions on them to avoid unmet dependencies, something like this:

Order:

// ...
export default sequelize.define('order', {/*...*/});
const Customer = require('./customer');
Order.belongsTo(Customer, {foreignKey: 'local_customer_id', targetKey: 'id'});

Customer:

export default sequelize.define('customer', {/*...*/});
const Order = require('./order');
Customer.hasMany(Order, {foreignKey: 'id', targetKey: 'local_customer_id'});

[alitaheri]

What is that export default syntax? Is that ECMA 6?

yeah it is 😁, you can just do module.exports = Order; no difference.

Ahh, I wondered about that asynchronous nature being the culprit.

Actually it’s not asynchronous at all, it’s just that when you require a module node will try to load it, now if you have something like this:

// main.js
require('./a');

// a.js
require('./b').foo; // Expected to be one, but is undefined !!
exports.bar = 1;

// b.js
exports.foo = require('./a').bar;

You would expect that foo should be 1! but it’s not!

let’s reason about what is happening.

1. the main.js is read by node.
2. node tries to evaluate a.js
3. node sees require('./b')
   • at this point the exports object doesn’t have the bar yet! node has not yet “seen” the exports.bar = 1; line
4. node tries to evaluate b.js
5. node sees require('./a')
6. node has a cache for './a'! so it simply returns that not-fully-initialized-cached-version of './a'
7. node sees .bar
8. but './a' doesn’t have .bar yet! so it assigns undefined to foo!
9. evaluation of './b' finishes!
10. node goes back to './a' to continue execution.
11. node sees .foo
12. but .foo was set to undefined in 8! so it also assigns undefined to .bar
13. NOW node assigns 1 to .bar which is too late (same reason for the error you saw)
14. evaluation of './a' ends
15. node goes back to './main'
16. evaluation of './main' ends
17. the event-loop is empty the process gets terminated,
18. unhappy ending 😢

only if in a.js we did this instead:

exports.bar = 1;
require('./b').foo;

We would all go home happy 😄

This is the reason why you see that error. you should understand how imperative programming languages work, and since js is single threaded it’s absolutely imperative.