OneTable CLI for DynamoDB Migrations

onetable-cli

The DynamoDB OneTable CLI is a command line tool for orchestrating DynamoDB migrations when using DynamoDB OneTable and OneTable Migrate.

The CLI is ideal for development teams to initialize and reset database contents and for production use to control and sequence step-wise database upgrades.

OneTable is used by the SenseDeep Serverless Developer Studio for all DynamoDB access. OneTable is provided open source (MIT license) from GitHub OneTable or NPM OneTable.

OneTable CLI Features

  • Simple command line utility to control and manage DynamoDB schema and contents.
  • Mutate database schema and contents via discrete, reversible migrations.
  • Migrate upwards, downwards, to specific versions.
  • Automated, ordered sequencing of migrations in both directions.
  • Operate on local databases, remote databases via AWS credentials and via Lambda proxy.
  • Add and remove seed data in any migration.
  • Quick reset of DynamoDB databases for development.
  • Show database status and list applied migrations.
  • Show outstanding migrations.
  • Stored history of migrations.

Installation

npm i onetable-cli -g

Getting Started

To get started, create a directory for your migrations in your project.

mkdir ./migrations

Then create a migrate.json with your DynamoDB OneTable configuration. We use JSON5 so you can use Javascript object literal syntax.

{
    name: 'your-dynamo-table',
    schema: 'schema.js',
}

Set the name property to the name of your DynamoDB table. Set the schema property to point to your OneTable schema.

If you need to have your migrations in a different directory, you can set onetable.dir to point to the directory containing the migrations themselves.

Your configuration should match your OneTable configuration with respect to the OneTable crypto, delimiter, nulls and typeField settings.

Generate a stub migration

Migrations are Javascript files that export the methods up and down to apply the migration and a description property.

onetable generate

This will create a 0.0.1.js migration that contains the following. Edit the up and down methods and description to suit. The db property is the OneTable Table instance. This migrate property is an instance of the CLI Migrate class.

export default {
    description: 'Purpose of this migration',
    async up(db, migrate) {
        // await db.create('Model', {})
    },
    async down(db, migrate) {
        // await db.remove('Model', {})
    }
}

Examples

Apply the next migration.

onetable up

Reverse the last migration.

onetable down

Migrate to a specific version (up or down).

onetable 0.1.3

Apply all outstanding migrations.

onetable all

Show the last applied migration.

onetable status

Show applied migrations.

onetable list

Show outstanding migrations not yet applied.

onetable outstanding

Reset the database to the latest migration. This should the database and apply the latest.js migration. The purpose of the latest migration is to have one migration that can quickly create a new database with the latest schema without having to apply all historical migrations.

onetable reset

Generate a specific version migration

onetable --bump 2.4.3 generate

Do a dry run for a migration and not execute

onetable --dry up

Command Line Options

--aws-access-key                    # AWS access key
--aws-region                        # AWS service region
--aws-secret-key                    # AWS secret key
--bump [major,minor,patch]          # Version digit to bump in generation
--config ./migrate.json             # Migration configuration
--crypto cipher:password            # Crypto to use for encrypted attributes
--dir directory                     # Change to directory to execute
--dry                               # Dry-run, don't execute
--endpoint http://host:port         # Database endpoint
--force                             # Force action without confirmation
--profile prod|qa|dev|...           # Select configuration profile
--quiet                             # Run as quietly as possible
--schema ./path/to/schema.js        # Database schema module
--version                           # Emit version number

Accessing AWS

You can configure access to your DynamoDB table in your AWS account several ways:

  • via command line options
  • via the migrate.json
  • via environment variables
  • via proxy

Via command line option:

onetable --aws-access-key key --aws-secret-key secret --aws-region us-east-1

Via migrate.json

{
    aws: {
        accessKeyId: 'your-key',
        secretAccessKey: 'your-access',
        region: 'us-east-1'
    }
}

Or via environment variables:

export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key
export AWS_DEFAULT_REGION=us-east-1

You can also use:

export AWS_PROFILE=aws-profile-name
export AWS_REGION=us-east-1

To access a local DynamoDB database, set the migrate.json aws.endpoint property to point to the listening endpoint.

{
    aws: {
        endpoint: 'http://localhost:8000'
    }
}

To communicate with a Lambda hosting the OneTable Migrate Library, set the arn field to the ARN of your Lambda function. Then define your AWS credentials as described above to grant access for the CLI to your Lambda.

{
    arn: 'arn:aws:lambda:us-east-1:123456789012:function:migrate-prod-invoke'
}

Remote Connections

The OneTable CLI uses the OneTable Migrate controller library internally to manage migrations. As such, DynamoDB I/O is performed from within the OneTable CLI process. This means I/O travels to and from the system hosting the OneTable CLI process.

While this is fine for development databases and smaller DynamoDB tables, if you have very large database updates, you should run the CLI process from a Lambda in the same AWS region and AZ as your DynamoDB instance. For large databases or complex migrations, this will greatly accelerate your database migrations compared with running the CLI on-prem.

If you have large databases or complex migrations, you should host the OneTable Migrate library via AWS Lambda so that it executes in the same AWS region and availablity zone as your DynamoDB instance. This will accelerate migrations by minimizing the I/O transfer time. With this split deployment of CLI and Migration library, higher volume migrations execute more quickly.

To configure remote control of migrations, set the migrate.json arn property to the ARN of your migration Lambda that hosts the Migration Library. See OneTable Migrate for more details about Lambda hosting of the OneTable Migrate library.

Latest Migration

You can create a special latest migration that is used for the migrate reset command which is is a quick way to get a development database up to the current version.

The latest migration should remove all data from the database and then initialize the database equivalent to applying all migrations.

When creating your latest.js migration, be very careful when removing all items from the database. We typically protect this with a test against the deployment profile to ensure you never do this on a production database.

Sample latest.js migration:

export default {
    description: 'Database reset to latest version',
    async up(db, migrate) {
        if (migrate.params.profile == 'dev') {
            await removeAllItems(db)
        }
        //  Provision required database data
    },
    async down(db, migrate) {
        if (migrate.params.profile == 'dev') {
            await removeAllItems(db)
        }
    },
}
async function removeAllItems(db) {
    do {
        items = await db.scanItems({}, {limit: 100})
        for (let item of items) {
            await db.deleteItem(item)
        }
    } while (items.length)
}

Why OneTable?

DynamoDB is a great NoSQL database that comes with a steep learning curve. Folks migrating from SQL often have a hard time adjusting to the NoSQL paradigm and especially to DynamoDB which offers exceptional scalability but with a fairly low-level API.

The standard DynamoDB API requires a lot of boiler-plate syntax and expressions. This is tedious to use and can unfortunately can be error prone at times. I doubt that creating complex attribute type expressions, key, filter, condition and update expressions are anyone’s idea of a good time.

Net/Net: it is not easy to write terse, clear, robust Dynamo code for one-table patterns.

Our goal with OneTable for DynamoDB was to keep all the good parts of DynamoDB and to remove the tedium and provide a more natural, “Javascripty” way to interact with DynamoDB without obscuring any of the power of DynamoDB itself.

More?

You can read more in the detailed documentation at:

SenseDeep with OneTable

At SenseDeep, we’ve used OneTable and the OneTable CLI extensively with our SenseDeep serverless developer studio. All data is stored in a single DynamoDB table and we extensively use single table design patterns. We could not be more satisfied with DynamoDB implementation. Our storage and database access costs are insanely low and access/response times are excellent.

Please try our Serverless developer studio SenseDeep.

Participate

All feedback, contributions and bug reports are very welcome.

Links

Comments Closed

{{comment.name || 'Anon'}} said ...

{{comment.message}}
{{comment.date}}

Try SenseDeep

Start your free 14 day trial of the SenseDeep Developer Studio.

© SenseDeep® LLC. All rights reserved. Privacy Policy and Terms of Use.

Consent

This web site uses cookies to provide you with a better viewing experience. Without cookies, you will not be able to view videos, contact chat or use other site features. By continuing, you are giving your consent to cookies being used.

OK