Optional Readonly createCreate the DynamoDB table if it does not exist with OnDemand capacity
⛔️ NOT SUGGESTED ⛔️: this can create the table in many accounts and regions for any developer running the app locally with AWS credentials that have permission to create tables. This is also a bad idea because the least expensive option for relatively stable loads is to use ProvisionedCapacity with Application Auto Scaling configured to adjust the Read and Write capacity.
Set to {} enable creation of the table with default parameters, or
specify additional parameters.
undefined - table will not be created
Optional Readonly dynamoDBClientAWS v3 SDK DynamoDB client, optionally wrapped with XRay, etc.
new DynamoDBClient({})
Optional Readonly hashHash key name of the existing DynamoDB table or name of the hash key
to create if the table does not exist and the createTableOptions
do not provide a hash key name.
'id'
Optional Readonly prefixPrefix to add to the sid in the hashKey written to the DynamoDB table.
'session#'
Optional Readonly tableName of the DynamoDB table to use (and optionally create)
'sessions'
Optional Readonly touchOnly update the session TTL on touch events if touchAfter seconds has passed
since the last time the session TTL was updated.
Set to 0 to always update the session TTL. - This is not suggested.
Writes on DynamoDB cost 5x as much as reads for sessions < 1 KB.
Writes on DynamoDB cost 20x as much as reads for sessions >= 3 KB and < 4 KB
Managing settings on DynamoDB provisioned capacity tables
UpdateItem — Modifies a single item in the table. DynamoDB considers the size of the item as
it appears before and after the update. The provisioned throughput consumed reflects the
larger of these item sizes. Even if you update just a subset of the item's attributes,
UpdateItem will still consume the full amount of provisioned throughput (the larger of the
"before" and "after" item sizes).
3600 (1 hour) or 10% of the ttl if ttl is less than 36,000 (10 hours)
Optional Readonly useUse Strongly Consistent Reads for session reads
Strongly Consistent Reads should rarely be needed for a session store unless the values in the session are updated frequently and they must absolutely be the most recent version (which is very unliley as the most recent write could fail, in which case the session would not be the most recent version...).
Reasons not to use Strongly Consistent Reads:
false
Generated using TypeDoc
DynamoDBStoreOptions are the options for creating a DynamoDBStore