search

dapr / components-contrib

Community driven, reusable components for distributed apps
Apache License 2.0
540 stars 468 forks source link

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

Open passuied opened 4 months ago

passuied commented 4 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

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 4 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 3 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:

@yaron2 as usual your opinion is appreciated.

yaron2 commented 3 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 3 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)

github-actions[bot] commented 2 months ago

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

yaron2 commented 2 months ago

/keepalive

github-actions[bot] commented 1 month ago

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

passuied commented 1 month ago

/keepalive

github-actions[bot] commented 3 weeks ago

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

yaron2 commented 3 weeks ago

/keepalive