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

passuied commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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)