Users/davetheunissen/query metrics option #38
Conversation
This is related to issue #21 and is required to expose query metrics to the calling client
| /// <summary> | ||
| /// Contains the metadata from the response headers from the Azure Cosmos DB call | ||
| /// </summary> | ||
| public IEnumerable<T> Resources; |
There was a problem hiding this comment.
Why is this being made public? The CosmosQueryResponse already implements IEnumerable.
There was a problem hiding this comment.
As far as I can tell, there is no way to cast the Resources object to CosmosQueryResponse<T> because internally it is of Type FeedResponse<T>.
The only alternate I can see is to create a public property in CosmosQueryResponse that returns FeedOptions<T> from Resources. Not sure that this is great option though?
If you have an example of how this might work, I'm happy to learn and ammend the PR etc.
There was a problem hiding this comment.
@kirankumarkolli any suggestions?
There was a problem hiding this comment.
Wouldn't the CosmosResultSetIterator work to iterate with any type, like it works for CreateItemQuery?
There was a problem hiding this comment.
If I create a CosmosResultSetIterator<FeedReponse<T>> FetchNextSetAsync throws an exception because the document coming back from CosmosDB doesn't match that type.
CosmosResultSetIterator<T> returns an enumerable collection of CosmosQueryResponse. CosmosQueryResponse<T> returns an enumerator of Resources<FeedResponse<T>>. The FeedResponse includes the meta properties about the request so we don't need to enumerate Resources, we just need access to the FeedResponse<T> properties.
Given that FeedResponse<T> is an internal class, there isn't a way to create a public accessor property without changing the internal scope.
If there is an issue with making Resources public then I'll need to try something else to get at the FeedResponse properties.
Appreciate any help or thoughts.
There was a problem hiding this comment.
Should there be a (new) public IQueryMetrics interface that IFeedResponse<T> would inherit from, and that's the interface we would use to expose query metrics from CosmosQueryResponse<T> through the Resources property? (although I don't think "Resources" would be a good name for that purpose)
There was a problem hiding this comment.
The IFeedResponse<T> interface already contains all the properties that we'd like to expose... incl. query metrics... however that's also scoped as internal. I'll have another crack at this on the weekend.
This PR relates to issues #21 and #33
Added the PopulateQueryMetrics property to the CosmosQueryRequestOptions class and maped to underlying FeedOptions.
Updated CosmosQueryResponse Resources to be public so that the meta for the response is available to the calling client
Added a unit test to ensure that QueryMetrics are populated when the PopulateQueryMetrics feed option is set.