Migrating Data

This guide will help you use migrations when you need to change the data or execute a piece of code outside of the regular application running cycle, for example, when you want to seed data on each environment.

Requirements

This is an advanced tutorial. To follow it, you should be familiar with basic platformOS concepts, and the topics in the Get Started section.

Steps

Migrating data is a three-step process:

Step 1: Generate empty migration

Generate an empty migration using the pos-cli migrations command:


pos-cli migrations generate ENVIRONMENT MIGRATION_NAME

For example:


pos-cli migrations generate local add_some_books

On success, this generates an empty migration in the app/migrations directory.

You can use the list command to see all migrations created on an environment:


pos-cli migrations list local

Please note that the name you provide will be prefixed with a UTC timestamp, that looks like this: 20180731120002. In this example, the file created will be named something like this: 20180909123423_add_some_books.liquid.
This value is used to keep the migrations in order in all environments. Do not change this value by hand, and do not skip this step by simply adding a file in the migrations/ directory because it may cause errors.

Step 2: Implement migration

Use the Liquid markup in migration files, that includes executing GraphQL mutations (graphql tag). A migration file can be synced many times.

For example, the following mutation can be put into the file created by the command in step 1:


{% graphql res = 'create_book', name: "Animal Farm", author: "George Orwell" %}

Note

Be careful about using deploys with migrations that are not ready, because deployment runs all migrations that are in pending status.

Step 3: Run migration

Note

You can use deploy or sync, but the migration you want to execute has to be delivered to the target environment first.

The deployment will upload and try to run migrations one by one (ordered by timestamp) and it will fail if one of the migrations fails. In the context of modules, migrations are run when the deployment is done through the Partner Portal or using the pos-cli deploy -p option.

The pos-cli migrations run command starts a background process that runs a single migration:


pos-cli migrations run ENVIRONMENT MIGRATION_TIMESTAMP

For example:


pos-cli migrations run local 20180909123423

Note

For the command, you have to provide the timestamp, not the full name, for example: 20180731120002

A newly created migration is in pending status for as long as it has not been run. Once it's executed (either through a deploy or using the migrations run command), it progresses to either done (on success) or error status.

You can check the status of all migrations using the pos-cli migrations list command.

Once a migration is in the done status, it can't be run anymore - this makes it safer to run the same queue of migrations on all environments.

When an error occurs, the migration can be edited and rerun until it succeeds.

Although migrations are run in a background worker and will not affect the performance of your site, we encourage using Data Import/Export for any larger data processing jobs. Migrations are best for seeding data and doing small changes to a model schema.

Questions?

We are always happy to help with any questions you may have.