components-contrib
components-contrib copied to clipboard
Query API: CosmosDB does not support non-string values in query
The current cosmosDB package github.com/a8m/documentdb
does not support non-string values in the query.
See https://github.com/a8m/documentdb/blob/master/query.go#L5
However, non-string values work fine when querying cosmosDB directly from the Data Explorer.
Possible solution:
- replacing https://github.com/a8m with another (Microsoft?) SDK
- fixing github.com/a8m/documentdb
Given that there is no official SDK or even an unofficial popular SDK, I would propose going with (2).
Some time back MSFT recommended another SDK , vippsas/go-cosmosdb, but it does not have commits since 2 years.
This is the official SDK https://github.com/Azure/azure-sdk-for-go/tree/main/sdk/data/azcosmos
Open PR to document the same https://github.com/MicrosoftDocs/azure-docs-pr/pull/190596
Please see this tracking issue @shubham1172 #1526
Can we close this issue?
@shubham1172 Why was this issue closed ? This is still an issue with cosmosdb unless there was a fix done to the dependent library and updated in go.mod in contrib ....
@mukundansundar isn't there another issue to track the same? This was an enhancement issue to change the cosmos DB library, and #1526 already tracks it.
@shubham1172 That is for tracking the sdk update ... but checking if non-string values work is not a priority for that issue imo. I think this should be kept open.
Sure, let's open it and label it as a bug then?
reopening this and labelling as bug
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.
In v1.9 we upgraded to the new Azure SDK, so this likely is not a problem anymore. However, it has also been discussed that Query API will not leave Alpha state.
Instead we will be introducing a DocumentStore building block. Cosmos DB itself will eventually exist as a DocumentStore and a proper Query API will be implemented there.
Closing this as probably fixed already / wontfix.