Why we need to define structure of database TWICE?

[webman]

Why we need to define structure of database TWICE?

1. Migrations folder: /migrations/XXXXXXX_modelname.js
2. Models folder: /models/modelname.js

It's kind of weird, no?

[kjloveless]

@Webman I may be a little off with the answer, but here it goes.

The model is used to represent the table as an object.

A migration is used to transition the database state, so if you add or remove something from your model you can run a migration and it will update the database. You can also undo migrations to return to a previous state, so say you needed to undo the change you made you could undo that migration and return to the previous instance of your database state.

Does this make sense or help?

[webman]

@kjloveless In other frameworks (such as Express, Adonis, Laravel) we not need to define structure twice. Usually done only migration (DB schema), but in model file dont specify structure. And this is comfortable for development - structure defined in one file.

[kjloveless]

@Webman I'm not sure I follow exactly what you're trying to get at honestly... You can think of the model as the object that you are going to get back from your database and the migration is simply a log of changes applied to your database. So you're really defining the structure of a table with the migration and of an object with the model... Does that make sense?

[https://laracasts.com/discuss/channels/laravel/the-difference-between-a-model-and-a-migration](Maybe this link will help?)

I do think it would be nice however if the migration files would be able to be generated based off the corresponding model file, but people has made additional libraries to solve this as well already. This would probably get rid of your feeling of defining things twice..

In summary, they're two separate thing...

@sushantdhiman can you confirm my answer? or clear things up for Webman if I misspoke?

[ryanburnette]

I advocate this example repository being explicit in showing migration structure, but perhaps it could also give an example of how to skip the migrations and use sync.

[ryanburnette]

Another thing to consider is that generating a model with --attributes allows you to define the structure once, generating the model and migration. Edits would then require defining the same information twice though.

[DRoet]

Tracking issue for this is basically here: https://github.com/sequelize/sequelize/issues/5213

[webman]

After more experience with Sequelize and another ORMs I understand a lot of things in development and deploying projects. This is not issue, it is absolutely normal - defining structure in model and create few migrations for updating database structure through time.

I think current issue may be closed.

[papb]

Hi everyone, thanks for raising this issue, sorry to take so long to give you more attention. I believe this is a common question, I will try to improve the docs on this at some time, but a short answer is as follows.

Models are the main thing. The feature of migrations exist for version-controlling the state of your database; migrations are not mandatory. One can start to use migrations long after the database is already running, even in production. The duplicated structure that could be seen in the old example was caused by the decision of applying migrations since the very beginning, representing the state change from 'database does not even exist' to 'now database exists with these tables'. In my opinion, this is not very useful. What I would recommend is to just set up the database without migrations, and start using migrations only after your service is already running in production and you have to change something.

Feel free to ask me any further questions :grin: