Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(dynamodb): global tables version 2019.11.21 #5821

Merged
merged 21 commits into from Feb 11, 2020

Conversation

jogold
Copy link
Contributor

@jogold jogold commented Jan 15, 2020

Add support for global tables version 2019.11.21.

Version 2019.11.21 (current) of global tables enables to dynamically add new
replica tables from a table populated with data. It is more efficient and
consumes less write capacity than version 2017.11.29.

Uses the custom resource provider framework (async) to update the table
(onEvent) and check for replica creation (isComplete).

Tables no longer have to be created in separate "regional" stacks and then
"glued" together with a custom resource as in @aws-cdk/aws-dynamodb-global.
This means that a separate module is no longer justified.

Deprecate @aws-cdk/aws-dynamodb-global: it uses version 2017.11.29 and the API
and custom resource implementation for version 2019.11.21 is much cleaner.

See https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.V2.html

Closes #5752
Closes #5489
Closes #5516


By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

Add support for global tables version 2019.11.21.

Version 2019.11.21 (current) of global tables enables to dynamically add new
replica tables from a table populated with data. It is more efficient and
consumes less write capacity than version 2017.11.29.

Uses the custom resource provider framework (async) to update the table
(`onEvent`) and check for replica creation (`isComplete`).

Tables no longer have to be created in separate "regional" stacks and then
"glued" together with a custom resource as in `@aws-cdk/aws-dynamodb-global`.
This means that a separate module is no longer justified.

Deprecate `@aws-cdk/aws-dynamodb-global`: it uses version 2017.11.29 and the API
and custom resource implementation for version 2019.11.21 is much cleaner.

See https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.V2.html

Closes aws#5752
@jogold jogold requested a review from skinny85 as a code owner January 15, 2020 21:23
@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

latestSdkInstalled = true;
}

export async function onEventHandler(event: any): Promise<any> {
Copy link
Contributor Author

@jogold jogold Jan 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@eladb I was not able to use the framework types (AWSCDKAsyncCustomResource namespace) exported in @aws-cdk/custom-resources... any idea why? or how I could use them?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I export those types in lib/provider-framework/index.ts (export * from './types'), I can use them but then jsii complains when building @aws-cdk/custom-resources because types are extending types defined in @types/aws-lambda

Copy link
Contributor Author

@jogold jogold Jan 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course it works by deeply importing (import { IsCompleteResponse, OnEventResponse } from '@aws-cdk/custom-resources/lib/provider-framework/types';), this is OK inside this repo but not a good user experience for users consuming @aws-cdk/custom-resources

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@skinny85
Copy link
Contributor

I did not have time to look at this last week - @nija-at , it's all yours :).

@jogold
Copy link
Contributor Author

jogold commented Feb 10, 2020

We can maybe add something here to also close #5516. Looking into this.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: FAILED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@jogold
Copy link
Contributor Author

jogold commented Feb 11, 2020

@eladb do we want to expose an array of ITable representing the replica tables (with real CF dependency on the custom resource)? I'm not sure it's useful since you would not be able to consume it in a stack deployed in another region...

@eladb
Copy link
Contributor

eladb commented Feb 11, 2020

do we want to expose an array of ITable representing the replica tables

Maybe we can add this later

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Feb 11, 2020

Thank you for contributing! Your pull request is now being automatically merged.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@mergify
Copy link
Contributor

mergify bot commented Feb 11, 2020

Thank you for contributing! Your pull request is now being automatically merged.

@phstc
Copy link
Contributor

phstc commented Jan 20, 2022

@jogold @eladb I'm trying to enable pointInTimeRecovery on the regional tables, and I couldn't find any accessor to access individual tables. regionalArns is protected and globalReplicaCustomResources is private.

I'm wondering if this is by design, for example, if there's any limitation with global tables and global point in time recovery, or if we can expose or even enable it by default if the main table has pointInTimeRecovery: true

@skinny85
Copy link
Contributor

@phstc can you open us a separate issue about this? This PR is over 2 years old, not really a great place for this discussion I feel 🙂.

@phstc
Copy link
Contributor

phstc commented Jan 20, 2022

@skinny85 absolutely. Thanks for checking!

#18582

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants