aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
https://aws.amazon.com/cdk
Apache License 2.0
11.51k stars 3.86k forks source link

(aws-timestream): (Add property for modifying Schema / Partition Key) #26577

Open wz2b opened 1 year ago

wz2b commented 1 year ago

Describe the feature

I need a way from CDK to set the Schema element of CfnTableProps to allow the custom partitioning to work the way I want. Currently, this isn't supported anywhere throughout the stack, including Cloud Formation Cfn* libraries meaning I have no clear options, not even by using L1 constructs. I am unsure how to work around this.

See https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-timestream-table-schema.html for a description of what I mean.

Use Case

There is not a clear way to work around this. The table property cannot be modified once the table is created, so you have to be able to do it here. The only workaround I can think of is to remove the tables from CDK entirely and create them by some external means.

Proposed Solution

No response

Other Information

No response

Acknowledgements

CDK version used

2.89.0

Environment details (OS name and version, etc.)

Windows and Linux

pahud commented 1 year ago

Looks like cloudformation only allows you to set a list of partition keys in the table schema. Does this satisfy your schema requirement?

wz2b commented 1 year ago

Oddly enough I had to submit some doc update requests on the documentation for that, because what you describe is what the object model says its wants but in reality you have to specify a list of exactly length 1.

I was able to find a workaround for this. The workaround is to create the table using the CfnTable L1 construct, then do this:

    table.addPropertyOverride("Schema", {
        "CompositePartitionKey": [
            {"Name": "pk", "Type": "DIMENSION", EnforcementInRecord: "REQUIRED"}
        ]
    });

I described that here

This is all pretty frustrating but it seems to stem from changes made to the API on June 23 and the cloudformation libraries and documentation just haven't caught up yet. I think if the current API is long-lived then it still makes sense to add this to the L1 constructs as proper, typed objects.