Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide the RU's used by an operation #275

Open
SeanFarrow opened this issue May 13, 2022 · 9 comments
Open

Provide the RU's used by an operation #275

SeanFarrow opened this issue May 13, 2022 · 9 comments
Labels
help wanted Extra attention is needed up-for-grabs 🙏🏽 Happy to consider a pull review to address this issue

Comments

@SeanFarrow
Copy link

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.

@mumby0168
Copy link
Collaborator

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.

@SeanFarrow
Copy link
Author

@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?

@mumby0168
Copy link
Collaborator

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.

@dcuccia
Copy link
Collaborator

dcuccia commented May 18, 2022

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
Copy link
Author

SeanFarrow commented May 18, 2022 via email

@dcuccia
Copy link
Collaborator

dcuccia commented May 20, 2022

@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)

@karpikpl
Copy link

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

@IEvangelist IEvangelist added help wanted Extra attention is needed up-for-grabs 🙏🏽 Happy to consider a pull review to address this issue labels Apr 6, 2023
@IEvangelist
Copy link
Owner

@all-contributors please add @SeanFarrow for idea

@allcontributors
Copy link
Contributor

@IEvangelist

I've put up a pull request to add @SeanFarrow! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed up-for-grabs 🙏🏽 Happy to consider a pull review to address this issue
Projects
None yet
Development

No branches or pull requests

5 participants