You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our current convenient MetricSample data structure only exposes a limited fraction of the data in the API response. This is fine for the majority of the applications and there are no plans yet to rework it such that further data like states, bounds or more fields from aggregated metrics are integrated into the existing data structure.
Proposed solution
If we expose access to the underlying, auto-generated pb data structure, users are able access all data that can be retrieved from the UI.
This also needs an example implementation.
Use cases
Anything that needs bounds, states or fields other than mean in aggregate metrics.
Alternatives and workarounds
Rework the current data structure to represent everything. Since this will become very nested like the original response data structure, better would probably be to introduce a new data structure. However, it needs to be seen how much value this brings over the existing auto-generated version.
Activity
[-]Expose raw pb data [/-][+]Expose all response data [/+]flora-hofmann-frequenz commentedon Nov 1, 2024
@cwasicki can we look into this again? We already exposed options and bounds, should we continue with the new structure before v1.0.0?