@tables

Define DynamoDB tables with optional:

Global Secondary Indexes can be specified on each table you define using the @tables-indexes pragma.

Additionally, database changes can be streamed to a function with the @tables-streams pragma.

DynamoDB is a powerful database, though different from both SQL and NoSQL databases. It is highly recommended to dig into Amazon’s resources to familiarize yourself with it:

Syntax

Table name syntax

  • Lower + upper case alphanumeric string
  • Between 3 and 255 characters
  • Dashes, periods, and underscores are allowed
  • Must begin with a letter

Table structure syntax

  • Keys and Lambdas are defined by indenting two spaces
  • The required partition key is denoted by *
  • The optional sort key is denoted by **
  • Currently only *String, **String, *Number and **Number are supported
  • insert, update, and destroy events can be handled with @tables-streams

Note: app.arc creates fully isolated tables for staging and production.

Streaming Changes to a Lambda

Use the @tables-streams pragma to have Architect create a Lambda function which will receive events whenever items in the table get inserted, updated or deleted. Architect will create the Lambda for you locally under src/tables-streams/<tableName>.

Encrypting Tables

Define a encrypt property under a table definition to enable encryption at rest for your DynamoDB table. If encrypt is a boolean (i.e. encrypt true), then AWS will manage the encryption key. If a non-boolean is provided to encrypt (i.e. encrypt hithere), then the parameter is assumed to be an AWS Key Management Service custom master key ID.

Note: use of a custom master key will apply additional AWS KMS related charges

Time To Live

Time To Live (TTL) lets you define when items in a table expire so that they can be automatically deleted from the table. To specify a TTL attribute on items in a table, define an attribute name under the table definition and assign a value of TTL to it. For example, a definition of expires TTL would set the expires attribute on items in the table as holding the timestamp (in epoch) for when the item should expire.

Note: items are rarely deleted at the moment specified by the TTL attribute. They are typically deleted within 48 hours of the timestamp. Your application logic should still check the value of that attribute. The convenience here is not having to remember to delete data from your table that is time bound. It will get deleted, eventually.

Point-in-Time Recovery

DynamoDB has a feature which lets you recover your data to any point in time over the last 35 days (from the time it is enabled). Define a PointInTimeRecovery true property under a table definition to enable this feature.

Example

This app.arc file defines three database tables:

arc
@app
testapp

@tables
people
  pplID *String

cats
  pplID *String
  catID **String
  encrypt true
  PointInTimeRecovery true

fleeting-thoughts
  pplID *String
  expires TTL
json
{
  "app": "testapp",
  "tables": [
    {
      "people": {
        "pplID": "*String"
      },
      "cats": {
        "pplID": "*String",
        "catID": "**String",
        "encrypt": true,
        "PointInTimeRecovery": true
      },
      "fleeting-thoughts": {
        "pplID": "*String",
        "expires": "TTL"
      }
    }
  ]
}
yaml
---
app: testapp

tables:
- people:
    pplID: "*String"
- cats:
    pplID: "*String"
    catID: "**String"
    encrypt: true
    PointInTimeRecovery: true
- fleeting-thoughts:
    pplID: "*String"
    expires: "TTL"
Edit this doc on Github →
↑ @tables