@CosmosDBInput ignores partitionKey
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start with the @CosmosDBInput annotation on handleCommand and trace how its partitionKey value is resolved from the request body. Reproduce the example with the events collection, then verify whether the binding filters by the requested streamId; done means the binding returns only matching events or clearly documents the supported behavior.
Written by the indexing model from the issue text.
Description
In my Micronaut Azure Function I am using a binding @CosmosDBInput for event-sourcing like this:
public class ChatRoomFunction extends AzureFunction {
@FunctionName("handleCommand")
public HttpResponseMessage handleCommand(
@HttpTrigger(
name = "req",
methods = HttpMethod.POST,
authLevel = AuthorizationLevel.ANONYMOUS)
final HttpRequestMessage<Command> request,
@CosmosDBInput(
name = "events",
connectionStringSetting = CONNECTION_STRING,
databaseName = DATABASE_NAME,
collectionName = "events",
partitionKey = "events--{id}") final List<Event> events,
final ExecutionContext context
) {
// function body intentionally left out
}
}
// with
public class Command {
private UUID id;
// more fields, getters, setters
}
// and
public class Event {
private String streamId; // this is the CosmosDB partition key
// more fields, getters, setters
}
Before, I tried doing this using @TableInput which seemed to worked fine.
Now I've switched to CosmosDB and for some reason it seems to ignore my @CosmosDBInput's partitionKey value.
Expected: events should contain a list of only Events having a certain streamId as matched by the binding parameter of the request body, i.e. id.
Actual: events contains a list of ALL Events present in the events collection.
Am I missing something here? This is what the partitionKey is for, right?
- Dominant language
- Java
- Stars
- 45
- Forks
- 49
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/azure-functions-java-library
-
area:java-functions
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Azure/azure-functions-java-library#229 · 1 comment ·
-
area:java-functions
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Azure/azure-functions-java-library#222 · 1 reaction ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
area:java-functions
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
-
area:java-functions
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in Azure/azure-functions-java-library
Similar issues
-
area-deployment area-integrations triage:bot-seen
Difficulty 2/5 Half a day Newbie friendliness 86/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
apache/flink-agents#1156 ·
-
[source-shopify] FAILED bulk operation without partialDataUrl is silently treated as successful Openarea/connectors autoteam community connectors/source/shopify needs-triage team/use type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100