Amplify-cli: API (GraphQL with DynamoDB): Creating GSI reusing table's Partition Key

[lazy-var]

Not completely sure if this is a bug or feature request, but I need assistance on it.

graphql-transformer, code-gen?, bug, help-wanted, feature-request, enhancement.

Describe the bug
I need to create a table GSI (Global Secondary Index), setting as Partition Key the same field that is used as Partition Key on the main table (Primary Index).

Amplify CLI Version
3.16.0

To Reproduce
i.e.:
I have already created a model (running stack) with:
@key(fields: ["partitionKey", "sortKey"])
And afterwards I want to add:
@key(name: "GlobalSecondaryIndex", fields: ["partitionKey", "GSIsortKey"])
When running amplify api push I get:

Attempting to add a local secondary index to the tableName table in the stackName stack. Local secondary indexes must be created when the table is created.
There was an error pushing the API resource
Attempting to add a local secondary index to the tableName table in the stackName stack. Local secondary indexes must be created when the table is created.
Cause: Adding a @key directive where the first field in 'fields' is the same as the first field in the 'fields' of the primary @key.
How to fix: Change the first field in 'fields' such that a global secondary index is created or delete and recreate the model.

Expected behavior
Instead of a LSI (Local Secondary Index) I expect to create a GSI. This design works if it's done manually on DynamoDB website.

An expected behavior for @key (name: "gsi-name", fields [<partition-key>, <sort-key>] could be:

• on table creation -> create LSI
• on already deployed table -> create GSI

Additional context
Related issues: #1725 #1917

[attilah]

@Soek22 could you tell me what benefit are you looking for, what do you want to achieve when you create LSI/GSI for the same fields that is already key fields on your type?

[lazy-var]

Hello @attilah, thank you for your help. Sorry for my English if I haven't explained myself well, I don't want to use same fields:
For primary index: @key(fields: ["partitionKey", "sortKey"])
For GSI (secondary index): @key(name: "GlobalSecondaryIndex", fields: ["partitionKey", "GSIsortKey"])

I need them to only share same field as partition key(partitionKey), but sort them with different fields (sortKey and GSIsortKey).

This allows me to retrieve same data with two different data access patterns, plus sort data by different fields.

ie.: partitionKey=user_id; sortKey=item_id; GSIsortKey=item_name
Here I can retrieve/sort items by id or by name, for the same owner.

And I need the secondary Index to be a GSI instead of LSI, because I don't want to restrict my table's collection size limit to 10GB

Thank you very much in advance.

[Itempool]

I'm running into a similar issue. Here's my example:

I already had a model like this:

type Todo @model @key(fields: ["owner", "id"]) {
  owner: String!
  id: String!
  todo: String!
}

And I wanted to create a GSI with an "updatedAt" sort key but the same "owner" partition key. I tried this:

type Todo @model
  @key(fields: ["owner", "id"])
  @key(
    name: "ByDate"
    fields: ["owner", "updatedAt"]
    queryField: "listTodoByDate"
  )
{
  owner: String!
  id: String!
  todo: String!
  updatedAt: AWSDateTime
}

Upon amplify push, I got this error:

Attempting to add a local secondary index to the TodoTable table in the Todo stack. Local secondary indexes must be created when the table is created.

I feel like there should be a way to tell amplify to create a GSI instead of an LSI. Otherwise, I do not see how I can achieve my desired access pattern without destroying and recreating the model.

[Jkap7788]

+1 Absolute must have feature.

We are designing a table to represent historical data and expect our partitions to grow very large over time. In order to enable certain access patterns we require a GSI with the same partition key as the base table.

However, a LSI is NOT suitable as this will limit our collection size to 10GB.

There should be an option to create a GSI with the same partition key as the base table.

[attilah]

I was looking into the issue and it is not that straightforward to determine if something was deployed or newly introduced, etc, so making the LSI, GSI choice cannot be made implicitly based on that fact alone. The team will discuss the best approach to address this problem area.

[lazy-var]

Thank you very much @attilah. It’s not critical, as can be easily achieved through the aws web interface once the backend is deployed. But I thought it was good to point it out, as it is basic index configuration valid for plenty of use cases.

[attilah]

@Soek22 I was started to look into this issue before the holidays and discussed it with some team members and without breaking existing deployments there is not an easy way to fix it, the behavior of the @key directive must be changes/extended, so I mark it as an enhancement.

One approach we discussed would be a change that would involve extending the @key directive with an additional parameter where customers would be able to explicitly tell the CLI they want a GSI so when its specified then it would be created, otherwise the current logic would stay in place like an "auto" value for that parameter.

[lazy-var]

@Attilah that sounds perfect! Thank you for the solution.

[aehringer]

@attilah Any update on this? I have a model that cannot be removed/recreated and need this feature ASAP.

[Bulletninja]

model that cannot be removed/recreated and need this feature ASAP.

Were you able to solve it?

[VicFrolov]

@SwaySway Hello just wanted to check in to see if there is an ETA for the open PR, or if there is a quick workaround that doesn't require removing/adding the table?

[mikedizon]

@SwaySway Hello just wanted to check in to see if there is an ETA for the open PR, or if there is a quick workaround that doesn't require removing/adding the table?

@VicFrolov don't hold your breath waiting for a response