Skip to main content
← Back to list
01Issue
FeatureClosedSwamp CLIPublic
AssigneesNone

Relationships

#1861 Add AWS::DynamoDB::Table model to @swamp/aws/dynamodb

Opened by andrewpark93 · 8/27/2026

Problem

@swamp/aws/dynamodb 2026.08.26.1 exposes backup and global-table, but no ordinary DynamoDB table model. Repositories using CDK or CloudFormation therefore cannot represent, inventory, sync, or verify an AWS::DynamoDB::Table through Swamp without creating a custom parallel extension.

CardProof needs this type for read-only inventory and post-CDK verification of its proposed operational data plane. CDK remains the desired-state owner; this request does not require item data-plane operations.

Verified environment

  • Swamp CLI: 20260827.012103.0-sha.89734f5f
  • Extension: @swamp/aws/dynamodb@2026.08.26.1
  • swamp model type search dynamodb returns only @swamp/aws/dynamodb/backup and @swamp/aws/dynamodb/global-table.
  • No existing Swamp Lab feature request matching DynamoDB table was found before submission.

Requested model

Add @swamp/aws/dynamodb/table as models/table.ts, generated from the current AWS::DynamoDB::Table CloudFormation resource schema and following the existing AWS CloudControl factory conventions.

Required methods:

  • create
  • get
  • update
  • delete
  • sync
  • list

The global-argument and output schemas should cover the complete current CloudFormation resource rather than a CardProof-specific subset, including key and attribute definitions, billing/capacity configuration, GSIs and LSIs, Streams, TTL, PITR, encryption, deletion protection, resource policy, tags, table class, and returned identifiers such as table name, ARN, ID, and stream ARN where CloudControl exposes them.

List/factory outputs should retain deterministic resource data names so workflows can reference exact items with data.latest(...) without spec-name ambiguity.

Acceptance criteria

  • swamp model type search dynamodb returns @swamp/aws/dynamodb/table.
  • swamp model type describe @swamp/aws/dynamodb/table --json reports the six standard lifecycle/read methods.
  • swamp model create @swamp/aws/dynamodb/table <name> --json creates a valid, name-based definition scaffold with a Swamp-assigned immutable ID.
  • Model validation accepts a representative PAY_PER_REQUEST table with a composite key, GSI, PITR, TTL, Streams, SSE, deletion protection, and tags.
  • Read output preserves identifiers required for CEL wiring into Lambda event-source-mapping and verification workflows.
  • Factory/list data remains addressable by exact data name under current data.latest() ambiguity checks.
  • Item data-plane methods (PutItem, Query, Scan, and similar) remain out of scope.

Security and ownership constraints

  • Never surface credentials or item contents in model output.
  • Preserve CloudControl read-only and write-only property behavior.
  • Do not make this type a substitute for an application's runtime DynamoDB SDK path.
  • Keep deletion protection and destructive-method review visible to workflow authors.

Upstream repository: https://github.com/swamp-club/swamp-extensions

Environment

  • Extension: @swamp/aws/dynamodb@2026.08.26.1
  • swamp: 20260827.012103.0-sha.89734f5f
  • OS: darwin (aarch64)
  • Deno: 2.8.3
  • Shell: unknown
02Bog Flow
✓OPEN○TRIAGED○IN PROGRESS◉CLOSED

Closed

8/27/2026, 6:50:22 AM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.