DEV Community

Cover image for OneTable CLI for DynamoDB Migrations
Michael O'Brien
Michael O'Brien

Posted on • Originally published at sensedeep.com

OneTable CLI for DynamoDB Migrations

#aws #nosql #dynamodb #serverless

The DynamoDB OneTable Migration 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 Troubleshooter for all DynamoDB access. OneTable is provided open source (MIT license) from GitHub OneTable or NPM OneTable.

OneTable Migrate 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
Enter fullscreen mode Exit fullscreen mode

Getting Started

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

mkdir ./migrations
Enter fullscreen mode Exit fullscreen mode

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',
}
Enter fullscreen mode Exit fullscreen mode

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.

migrate generate
Enter fullscreen mode Exit fullscreen mode

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', {})
    }
}
Enter fullscreen mode Exit fullscreen mode

Examples

Apply the next migration

migrate up
Enter fullscreen mode Exit fullscreen mode

Reverse the last migration

migrate down
Enter fullscreen mode Exit fullscreen mode

Migrate to a specific version (up or down)

migrate 0.1.3
Enter fullscreen mode Exit fullscreen mode

Apply all outstanding migrations

migrate all
Enter fullscreen mode Exit fullscreen mode

Show the last applied migration

migrate status
Enter fullscreen mode Exit fullscreen mode

Show applied migrations

migrate list
Enter fullscreen mode Exit fullscreen mode

Show outstanding migrations not yet applied

migrate outstanding
Enter fullscreen mode Exit fullscreen mode

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.

migrate reset
Enter fullscreen mode Exit fullscreen mode

Generate a specific version migration

migrate --bump 2.4.3 generate
Enter fullscreen mode Exit fullscreen mode

Do a dry run for a migration and not execute

migrate --dry up
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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:

migrate --aws-access-key key --aws-secret-key secret --aws-region us-east-1
Enter fullscreen mode Exit fullscreen mode

Via migrate.json

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

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
Enter fullscreen mode Exit fullscreen mode

You can also use:

export AWS_PROFILE=aws-profile-name
export AWS_REGION=us-east-1
Enter fullscreen mode Exit fullscreen mode

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

{
    aws: {
        endpoint: 'http://localhost:8000'
    }
}
Enter fullscreen mode Exit fullscreen mode

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'
}
Enter fullscreen mode Exit fullscreen mode

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)
}
Enter fullscreen mode Exit fullscreen mode

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: GitHub OneTable or NPM OneTable.

SenseDeep with OneTable

At SenseDeep, we've used OneTable and the OneTable CLI extensively with our SenseDeep serverless troubleshooter. 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 trouble shooter SenseDeep.

Participate

All feedback, contributions and bug reports are very welcome.

Contact

You can contact me (Michael O'Brien) on Twitter at: @SenseDeepCloud, or email and ready my Blog.

To learn more about SenseDeep and how to use our troubleshooter, please visit https://www.sensedeep.com/.

Links

Top comments (0)

Read next

automq profile image

AutoMQ vs Apache Kafka: A Real AWS Cloud Bill Comparison

AutoMQ -

guilleojeda profile image

Containers on AWS: Comparing ECS and EKS

Guille Ojeda -

josephhazen profile image

Hosting My Resume in the Cloud with AWS Serverless: A Network Engineer's Perspective

Joseph Hazen -

bhatiagirish profile image

Create call center transcript summary using AWS Bedrock and Lambda - Anthropic Haiku

Girish Bhatia -