[AWS DynamoDB] Support range key when saving and retrieving an item

[passuied]

Describe the feature

DynamoDB currently doesn't support querying at all and I'm not even sure that's needed for state management.
Having said that, being able to use it for saving a K/V in an append-only ledger kind of mode using a sort/range key as an additional parameter is something we've been missing recently.

Suggested API changes

Component metadata

• Add rangeKey as optional metadata

- name: rangeKey
    required: false
    description: |
      The table range key
    example: '"Timestamp"'
    type: string

Saving an item with range key

with DaprClient() as client:
        client.save_state("state-dynamo", "order_1", str(orderId), { "rangeKey": datetime.now().isoformat()}) 

Getting an item based on partition key and range key predicate

with DaprClient() as client:
    result = client.get_state("state-dynamo", "order_1", { "rangeKeyPredicate": "#rk > :value", ":value": datetime(2024, 1,1).isoformat(), "rangeKeySortAscending", "False" }})

Returns the item with latest timestamp greater than '01-01-2024'

Release Note

RELEASE NOTE: ADD support for range key save/retrieval in DynamoDB state management

[berndverst]

No objections from me (though I do not specialize in AWS components). It sounds useful and implementing via the metadata makes sense.

PRs welcome - but if PRs are added a test case should also be added in the certification test under tests/certification/state/aws/dynamodb

[passuied]

Thanks @berndverst, I'm wondering whether the sort key filtering settings should be in the component itself (more discrete) or in the state_metadata. I can see it both ways:

• Much cleaner and DRY code if in components
• More flexibility in case there are different usecases for key retrieval changes within the same service... Would prevent having to define multiple components...
  I'm leaning towards second...

@yaron2 as usual your opinion is appreciated.

[yaron2]

Thanks @berndverst, I'm wondering whether the sort key filtering settings should be in the component itself (more discrete) or in the state_metadata. I can see it both ways:

• Much cleaner and DRY code if in components
• More flexibility in case there are different usecases for key retrieval changes within the same service... Would prevent having to define multiple components...
  I'm leaning towards second...

@yaron2 as usual your opinion is appreciated.

Can have best of both worlds. Put it in component spec and then check to see if a key was provided on a request metadata and override if it exists

[passuied]

Thanks @berndverst, I'm wondering whether the sort key filtering settings should be in the component itself (more discrete) or in the state_metadata. I can see it both ways:

• Much cleaner and DRY code if in components
• More flexibility in case there are different usecases for key retrieval changes within the same service... Would prevent having to define multiple components...
  I'm leaning towards second...

@yaron2 as usual your opinion is appreciated.

Can have best of both worlds. Put it in component spec and then check to see if a key was provided on a request metadata and override if it exists

Yeah I was thinking the same... I'll probably start on the component spec and depending how it goes, expand to request metadata (in same PR or separate)