Skip to main content

Migrations

General​

Migrations are used to alter a database by modifying its schema and/or content.

The up functionality of a migration runs to make the intended database changes.

When a migration fails, the down functionality runs with the aim to restore the data to the previous state.

How to write a migration​

The migration scripts are located under hub/main/tools/db-migrate/migrations .

Utils with the most common migration functionality can be found under hub/main/tools/db-migrate/utils.js.

Further utils for more specific edgecase usage are found under hub/main/tools/db-migrate/utils.

See hub/main/tools/db-migrate/README.md on how to add and run new migrations.

Best practices​

  • Ensure each step run within the migration has an up and an appropriate down. When using the migration utils they'll handle both up and down for you

  • When updating tables, make sure to prevent the automatic update of the updated_time field, by setting updated_time = updated_time.

    Usecase example:

    const Runner = require('../runner');

    const q = [
      {
        up: 'UPDATE nudgeAction SET scheduled_offset = 0, updated_time = updated_time WHERE type = "remind"',
        down: 'UPDATE nudgeAction SET scheduled_offset = NULL, updated_time = updated_time WHERE type = "remind"'
      }
    ];

    module.exports = new Runner(q);

  • Migrations that change a large amount of data should be checked to ensure that they won't take too long when being deployed to production. A clean version of the prod data can be found here on Google drive for testing. Any migrations that will take too long will need to be put into their own migration script and should be discussed with the team before being merged.

Further resources​