Advance Topics

Migration Skeleton

The following skeleton shows a typical migration file.

  1. module.exports = {
  2. up: (queryInterface, Sequelize) => {
  3. // logic for transforming into the new state
  4. },
  5. down: (queryInterface, Sequelize) => {
  6. // logic for reverting the changes
  7. }
  8. }

We can generate this file using migration:generate. This will create xxx-migration-skeleton.js in your migration folder.

  1. $ npx sequelize-cli migration:generate --name migration-skeleton

The passed queryInterface object can be used to modify the database. The Sequelize object stores the available data types such as STRING or INTEGER. Function up or down should return a Promise. Let's look at an example:

  1. module.exports = {
  2. up: (queryInterface, Sequelize) => {
  3. return queryInterface.createTable('Person', {
  4. name: Sequelize.STRING,
  5. isBetaMember: {
  6. type: Sequelize.BOOLEAN,
  7. defaultValue: false,
  8. allowNull: false
  9. }
  10. });
  11. },
  12. down: (queryInterface, Sequelize) => {
  13. return queryInterface.dropTable('Person');
  14. }
  15. }

The following is an example of a migration that performs two changes in the database, using a transaction to ensure that all instructions are successfully executed or rolled back in case of failure:

  1. module.exports = {
  2. up: (queryInterface, Sequelize) => {
  3. return queryInterface.sequelize.transaction((t) => {
  4. return Promise.all([
  5. queryInterface.addColumn('Person', 'petName', {
  6. type: Sequelize.STRING
  7. }, { transaction: t }),
  8. queryInterface.addColumn('Person', 'favoriteColor', {
  9. type: Sequelize.STRING,
  10. }, { transaction: t })
  11. ])
  12. })
  13. },
  14. down: (queryInterface, Sequelize) => {
  15. return queryInterface.sequelize.transaction((t) => {
  16. return Promise.all([
  17. queryInterface.removeColumn('Person', 'petName', { transaction: t }),
  18. queryInterface.removeColumn('Person', 'favoriteColor', { transaction: t })
  19. ])
  20. })
  21. }
  22. };

The next is an example of a migration that has a foreign key. You can use references to specify a foreign key:

  1. module.exports = {
  2. up: (queryInterface, Sequelize) => {
  3. return queryInterface.createTable('Person', {
  4. name: Sequelize.STRING,
  5. isBetaMember: {
  6. type: Sequelize.BOOLEAN,
  7. defaultValue: false,
  8. allowNull: false
  9. },
  10. userId: {
  11. type: Sequelize.INTEGER,
  12. references: {
  13. model: {
  14. tableName: 'users',
  15. schema: 'schema'
  16. }
  17. key: 'id'
  18. },
  19. allowNull: false
  20. },
  21. });
  22. },
  23. down: (queryInterface, Sequelize) => {
  24. return queryInterface.dropTable('Person');
  25. }
  26. }

The next is an example of a migration that has uses async/await where you create an unique index on a new column:

  1. module.exports = {
  2. async up(queryInterface, Sequelize) {
  3. const transaction = await queryInterface.sequelize.transaction();
  4. try {
  5. await queryInterface.addColumn(
  6. 'Person',
  7. 'petName',
  8. {
  9. type: Sequelize.STRING,
  10. },
  11. { transaction }
  12. );
  13. await queryInterface.addIndex(
  14. 'Person',
  15. 'petName',
  16. {
  17. fields: 'petName',
  18. unique: true,
  19. },
  20. { transaction }
  21. );
  22. await transaction.commit();
  23. } catch (err) {
  24. await transaction.rollback();
  25. throw err;
  26. }
  27. },
  28. async down(queryInterface, Sequelize) {
  29. const transaction = await queryInterface.sequelize.transaction();
  30. try {
  31. await queryInterface.removeColumn('Person', 'petName', { transaction });
  32. await transaction.commit();
  33. } catch (err) {
  34. await transaction.rollback();
  35. throw err;
  36. }
  37. },
  38. };

The .sequelizerc File

This is a special configuration file. It lets you specify following options that you would usually pass as arguments to CLI:

  • env: The environment to run the command in
  • config: The path to the config file
  • options-path: The path to a JSON file with additional options
  • migrations-path: The path to the migrations folder
  • seeders-path: The path to the seeders folder
  • models-path: The path to the models folder
  • url: The database connection string to use. Alternative to using —config files
  • debug: When available show various debug information

Some scenarios where you can use it.

  • You want to override default path to migrations, models, seeders or config folder.
  • You want to rename config.json to something else like database.json

And a whole lot more. Let's see how you can use this file for custom configuration.

For starters, let's create an empty file in the root directory of your project.

  1. $ touch .sequelizerc

Now let's work with an example config.

  1. const path = require('path');
  2. module.exports = {
  3. 'config': path.resolve('config', 'database.json'),
  4. 'models-path': path.resolve('db', 'models'),
  5. 'seeders-path': path.resolve('db', 'seeders'),
  6. 'migrations-path': path.resolve('db', 'migrations')
  7. }

With this config you are telling CLI to

  • Use config/database.json file for config settings
  • Use db/models as models folder
  • Use db/seeders as seeders folder
  • Use db/migrations as migrations folder

Dynamic Configuration

Configuration file is by default a JSON file called config.json. But sometimes you want to execute some code or access environment variables which is not possible in JSON files.

Sequelize CLI can read from both JSON and JS files. This can be setup with .sequelizerc file. Let see how

First you need to create a .sequelizerc file in the root folder of your project. This file should override config path to a JS file. Like this

  1. const path = require('path');
  2. module.exports = {
  3. 'config': path.resolve('config', 'config.js')
  4. }

Now Sequelize CLI will load config/config.js for getting configuration options. Since this is a JS file you can have any code executed and export final dynamic configuration file.

An example of config/config.js file

  1. const fs = require('fs');
  2. module.exports = {
  3. development: {
  4. username: 'database_dev',
  5. password: 'database_dev',
  6. database: 'database_dev',
  7. host: '127.0.0.1',
  8. dialect: 'mysql'
  9. },
  10. test: {
  11. username: 'database_test',
  12. password: null,
  13. database: 'database_test',
  14. host: '127.0.0.1',
  15. dialect: 'mysql'
  16. },
  17. production: {
  18. username: process.env.DB_USERNAME,
  19. password: process.env.DB_PASSWORD,
  20. database: process.env.DB_NAME,
  21. host: process.env.DB_HOSTNAME,
  22. dialect: 'mysql',
  23. dialectOptions: {
  24. ssl: {
  25. ca: fs.readFileSync(__dirname + '/mysql-ca-master.crt')
  26. }
  27. }
  28. }
  29. };

Using Babel

Now you know how to use .sequelizerc file. Now let's see how to use this file to use babel with sequelize-cli setup. This will allow you to write migrations and seeders with ES6/ES7 syntax.

First install babel-register

  1. $ npm i --save-dev babel-register

Now let's create .sequelizerc file, it can include any configuration you may want to change for sequelize-cli but in addition to that we want it to register babel for our codebase. Something like this

  1. $ touch .sequelizerc # Create rc file

Now include babel-register setup in this file

  1. require("babel-register");
  2. const path = require('path');
  3. module.exports = {
  4. 'config': path.resolve('config', 'config.json'),
  5. 'models-path': path.resolve('models'),
  6. 'seeders-path': path.resolve('seeders'),
  7. 'migrations-path': path.resolve('migrations')
  8. }

Now CLI will be able to run ES6/ES7 code from migrations/seeders etc. Please keep in mind this depends upon your configuration of .babelrc. Please read more about that at babeljs.io.

Using Environment Variables

With CLI you can directly access the environment variables inside the config/config.js. You can use .sequelizerc to tell CLI to use config/config.js for configuration. This is explained in last section.

Then you can just expose file with proper environment variables.

  1. module.exports = {
  2. development: {
  3. username: 'database_dev',
  4. password: 'database_dev',
  5. database: 'database_dev',
  6. host: '127.0.0.1',
  7. dialect: 'mysql'
  8. },
  9. test: {
  10. username: process.env.CI_DB_USERNAME,
  11. password: process.env.CI_DB_PASSWORD,
  12. database: process.env.CI_DB_NAME,
  13. host: '127.0.0.1',
  14. dialect: 'mysql'
  15. },
  16. production: {
  17. username: process.env.PROD_DB_USERNAME,
  18. password: process.env.PROD_DB_PASSWORD,
  19. database: process.env.PROD_DB_NAME,
  20. host: process.env.PROD_DB_HOSTNAME,
  21. dialect: 'mysql'
  22. }
  23. };

Specifying Dialect Options

Sometime you want to specify a dialectOption, if it's a general config you can just add it in config/config.json. Sometime you want to execute some code to get dialectOptions, you should use dynamic config file for those cases.

  1. {
  2. "production": {
  3. "dialect":"mysql",
  4. "dialectOptions": {
  5. "bigNumberStrings": true
  6. }
  7. }
  8. }

Production Usages

Some tips around using CLI and migration setup in production environment.

1) Use environment variables for config settings. This is better achieved with dynamic configuration. A sample production safe configuration may look like.

  1. const fs = require('fs');
  2. module.exports = {
  3. development: {
  4. username: 'database_dev',
  5. password: 'database_dev',
  6. database: 'database_dev',
  7. host: '127.0.0.1',
  8. dialect: 'mysql'
  9. },
  10. test: {
  11. username: 'database_test',
  12. password: null,
  13. database: 'database_test',
  14. host: '127.0.0.1',
  15. dialect: 'mysql'
  16. },
  17. production: {
  18. username: process.env.DB_USERNAME,
  19. password: process.env.DB_PASSWORD,
  20. database: process.env.DB_NAME,
  21. host: process.env.DB_HOSTNAME,
  22. dialect: 'mysql',
  23. dialectOptions: {
  24. ssl: {
  25. ca: fs.readFileSync(__dirname + '/mysql-ca-master.crt')
  26. }
  27. }
  28. }
  29. };

Our goal is to use environment variables for various database secrets and not accidentally check them in to source control.

Storage

There are three types of storage that you can use: sequelize, json, and none.

  • sequelize : stores migrations and seeds in a table on the sequelize database
  • json : stores migrations and seeds on a json file
  • none : does not store any migration/seed

Migration Storage

By default the CLI will create a table in your database called SequelizeMeta containing an entryfor each executed migration. To change this behavior, there are three options you can add to theconfiguration file. Using migrationStorage, you can choose the type of storage to be used formigrations. If you choose json, you can specify the path of the file using migrationStoragePathor the CLI will write to the file sequelize-meta.json. If you want to keep the information in thedatabase, using sequelize, but want to use a different table, you can change the table name usingmigrationStorageTableName. Also you can define a different schema for the SequelizeMeta table byproviding the migrationStorageTableSchema property.

  1. {
  2. "development": {
  3. "username": "root",
  4. "password": null,
  5. "database": "database_development",
  6. "host": "127.0.0.1",
  7. "dialect": "mysql",
  8. // Use a different storage type. Default: sequelize
  9. "migrationStorage": "json",
  10. // Use a different file name. Default: sequelize-meta.json
  11. "migrationStoragePath": "sequelizeMeta.json",
  12. // Use a different table name. Default: SequelizeMeta
  13. "migrationStorageTableName": "sequelize_meta",
  14. // Use a different schema for the SequelizeMeta table
  15. "migrationStorageTableSchema": "custom_schema"
  16. }
  17. }

Note:The none storage is not recommended as a migration storage. If you decide to use it, beaware of the implications of having no record of what migrations did or didn't run.

Seed Storage

By default the CLI will not save any seed that is executed. If you choose to change this behavior (!),you can use seederStorage in the configuration file to change the storage type. If you choose json,you can specify the path of the file using seederStoragePath or the CLI will write to the filesequelize-data.json. If you want to keep the information in the database, using sequelize, you canspecify the table name using seederStorageTableName, or it will default to SequelizeData.

  1. {
  2. "development": {
  3. "username": "root",
  4. "password": null,
  5. "database": "database_development",
  6. "host": "127.0.0.1",
  7. "dialect": "mysql",
  8. // Use a different storage. Default: none
  9. "seederStorage": "json",
  10. // Use a different file name. Default: sequelize-data.json
  11. "seederStoragePath": "sequelizeData.json",
  12. // Use a different table name. Default: SequelizeData
  13. "seederStorageTableName": "sequelize_data"
  14. }
  15. }

Configuration Connection String

As an alternative to the —config option with configuration files defining your database, you canuse the —url option to pass in a connection string. For example:

  1. $ npx sequelize-cli db:migrate --url 'mysql://root:password@mysql_host.com/database_name'

Passing Dialect Specific Options

  1. {
  2. "production": {
  3. "dialect":"postgres",
  4. "dialectOptions": {
  5. // dialect options like SSL etc here
  6. }
  7. }
  8. }

Programmatic use

Sequelize has a sister library for programmatically handling execution and logging of migration tasks.