IEvangelist/azure-cosmos-dotnet-repository

Provide the RU's used by an operation

SeanFarrow opened this issue · 9 comments

I'm just starting to use this to replace a self-written interface to Cosmos.

The one thing my current interface gives me is the RU cost of an operation.

Could this be surfaced in some way through the repository interface(s)?

The Two options I can think of currently are introducing an ItemWrapper, rather than IItem--although you may want to keep this as it is useful, or extending IItem itself.

To my thinking the former is the better option, kind of like an HttpResponse.

Hi @SeanFarrow we do support this for some of the paging APIs. I think we could start logging this out if that is any help? We do in places but I think they are logged at Debug level.

@mumby0168
I suspected the information I wanted would be in the logs.

I'm using AppInsights, so use TelemetryClient to track this as a specific metric.
in terms of a solution to this, I can see two options:
Firstly, to change the signature of a method to provide the RU cost in the return value, which I don't think would make sense.
Or, have an out parameter on each method that provides the RU cost. Doing this would mean a user who isn't interested in this could discard that parameter.

I am right in that the second would make more sense? Or, do you have any other options?

Hi @SeanFarrow we would not want to modify the public API surface I do not think. So I don't think either the out parameter or the return type would work in this case. One option might be a set of new methods to all existing methods that allow you to collect the cost. But they would have to be new methods with new names. If we was to do that, I think I would prefer the return type option. out params can be a pain when using mocking libraries.

This seems like a cross-cutting concern - might it somehow be managed with an enclosing scope or wrapper class? Perhaps our core impl adds an pub/sub notification model using something like Mediatr for telemetry metrics of interest, including RUs, then those consumers that care can subscribe to those. That way it could be pay-to-play without adding complexity to the core API.

@SeanFarrow @mumby0168 if we published Mediatr-style events such as those demoed here:

https://youtu.be/NmmpXcMxCjY?t=665

...then the consuming code could follow a wrapper pattern like this:

https://www.youtube.com/watch?v=dLPKwEeqwgU&t=705s

(using Nick Chapsas videos as shortcuts...could publish some sample code when I have time this weekend)

Hi,
was this ever added? I see RUs in logs but I would like to access them programmatically.