Multiple GSI deploy using CDK construct

[jimjiminyjimjim]

Amplify CLI Version

12.2.5

Question

We're having problems deploying multiple GSI changes/creations using the CDK construct. Amplify CLI does this iteratively, and there are examples of using Lambda to create the GSIs but I don't think this would work alongside the graphql-api-contruct?

It does become a problem with multiple devs working on the project if we need to sync up work that contains multiple GSIs that have already been deployed iteratively to one region, and then we need to deploy to another region a different dev is working in as you can't really back track all the iterative index deploys.

Is there a way to do this with the CDK construct?

[sundersc]

@jimjiminyjimjim CDK construct uses a custom resource to deploy DynamoDB GSIs. It doesn't require iterative deployment, multiple index updates can be made in a single stack update. During deployment, it looks at the current table definition, then decides whether to create/update/drop a GSI. Could you explain the problem you are running into with an example schema?

[jimjiminyjimjim]

Here's a part of my schema:

if I add or remove multiple indexes for instance like this by adding byName and byDescription in one deploy:

I get this error:

12:57:12 AM | UPDATE_FAILED | AWS::DynamoDB::Table | ProductGroupTable59D4B7C7
Resource handler returned message: "Cannot perform more than one GSI creation or deletion in a single update" (RequestToken: d515adda-a0ba-c80f-ef1d-8aad26c5bb53, HandlerErrorCode: InvalidRequest)

Its fine if the table doesn't exist - its just if the table already exists with indexes

[sundersc]

I think you may be using the default table provisioning strategy which relies on DynamoDB constructs to manage the tables. DynamoDB constructs do not support more than one GSI creation or deletion in a single stack update. In order to use Amplify Table manager, the model provisioning strategy must be explicitly set as shown below.

definition: AmplifyGraphqlDefinition.fromString(schema, {
   dbType: 'DYNAMODB',
   provisionStrategy: 'AMPLIFY_TABLE'
}),

Refer to the corresponding helper definition here.

[jimjiminyjimjim]

Great thanks for pointing me towards this, is there any documentation other than the construct hub that would point out that this would be a feature of that provision strategy?

Also now I've changed it, some of my current constructs are struggling to find the tableRefs if I use something like this:

const tableRef = api.resources.cfnResources.cfnTables

as the cfnTables is an empty object. Will it need ripping down and starting again if I change the provisionStrategy? Or do I need to change my construct refs?

[AnilMaktala]

Hey @jimjiminyjimjim, Please note that changing the default provisioning policy may result in data loss. Ensure that you back up your data and enable delete protection before making any changes.

You can access the table map using api.resources.cfnResources.amplifyDynamoDbTables.