Until now, MySQL has not known anything about our plan to save posts inside of it. Our database tables and columns need to be created, of course, and this is why the migration file was created.

A migration file has multiple advantages, such as the following:

1. Migrations allow us to track database changes through our regular version control system, such as Git or SVN. Every change to our database structure should be covered in a migration file.
2. It also enables us to write updates that automatically apply database changes for new versions of our application.

Our first migration file creates a Posts table and adds all required columns, as follows:

'use strict';

module.exports = {
  up: (queryInterface, Sequelize) => {
    return queryInterface.createTable('Posts', {
      id: {
        allowNull: false,
        autoIncrement: true,
        primaryKey: true,
        type: Sequelize.INTEGER
      },
      text: {
        type: Sequelize.TEXT
      },
      createdAt: {
        allowNull: false,
        type: Sequelize.DATE
      },
      updatedAt: {
        allowNull: false,
        type: Sequelize.DATE
      }
    });
  },
  down: (queryInterface, Sequelize) => {
    return queryInterface.dropTable('Posts');
  }
};

By convention, the model name is pluralized in migrations, but it is singular inside of model definitions. Our table names are also pluralized. Sequelize offers options to change this.

A migration has two properties, as follows:

• The up property states what should be done when running the migration.
• The down property states what is run when undoing a migration.

As stated previously, the id and text column are created, as well as two additional datetime columns, to save the creation and update time.

The id field has set autoIncrement and primaryKey to true. The id will count upward, from one to nearly infinite, for each post in our table. This id uniquely identifies posts for us. Passing allowNull with false disables the feature to insert a row with an empty field value.

To execute this migration, we use the Sequelize CLI again, as follows:

sequelize db:migrate --migrations-path src/server/migrations --config src/server/config/index.js

Look inside of phpMyAdmin. Here, you will find the new table, called Posts. The structure of the table should look as follows:

All of the fields were created as we desired.

Furthermore, two additional fields, createdAt and updatedAt, were created. These two fields are what are called timestamps, and are used to tell when a row was either created or updated. The fields were created by Sequelize automatically. If you do not want this, you can set the timestamps property in the model to false.

Every time that you use Sequelize and its migration feature, you will have an additional table, called SequelizeMeta. The contents of the table should look as follows:

Sequelize saves every migration that has been executed. If we add further fields in development or in a new release cycle, we can write a migration that runs all table alterings for us as an update. Sequelize skips all migrations that are saved inside of the meta table.

One major step is to bind our model to Sequelize. This process can be automated by running sequelize init, but understanding it will teach us way more than relying on premade boilerplate commands.