Rumble in the DynamoDB

Leveraging cloud tools often bring in new challenges our way. Here's something I've learnt recently on working with DynamoDB.

When working on a table, if you try to modify more than one GSI at the same time it will shout back at you and deny following the course you're charting! That may be problematic, but on simple projects there are great ways to get around it.

Option 1 (for when you are working with a new table and did what a sane person would do, which is incrementally developed your solution):

change name & create it anew - only update and delete seem to be counting towards the action limit on the indices. When you create the table from scratch with a bunch of indices it seems to be working just fine!

Option 2 - for when you have data in the tables already, and they've been part of your stack for a bit (also assumes you've been referring to them in you applications through the exports of CloudFormation references):

Step 1: Download the database:

aws dynamodb scan --table-name ${STAGE}-${TABLE_NAME} \
| jq '{"${TARGET_STAGE}": [.Items[] | {PutRequest: {Item: .}}]}' > ${TARGET_STAGE}-${TABLE_NAME}.json

Step 2: Create the new database - don't adjust the old one, just create the new one first ( form me it's running stack deploy in the form of:

sls deploy -v

Step 3: Re-upload the data to the newly created database (it will assume the table name based on the grouping provided in Step 1:

aws dynamodb batch-write-item --request-items file://${TARGET_STAGE}-${TARGET_NAME}.json

Step 4: Replace the reference to the old table with a reference to the new table.
Step 5: Confirm everything works fine.
Step 6: Remove the old table.
Step 7: Live long and prosper (also celebrate, you gave the pesky tool a middle finger!)