oxidecomputer / oxidecomputer/omicron
Simplify oxql responses
Open
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
Description
Here's an excerpt of the response from the timeseries query endpoint:
"values": [
{
"metric_type": "delta",
"values": {
"type": "integer",
"values": [
118824099830713,
4957551326,
4966427295,
4956182957,
4958472616
]
}
}
]
I think this can be simpler in a few ways:
- The metric and value types are properties of the metric, so I think we can hoist them to the level of the table, rather than nesting them and repeating them for each timeseries.
- We have a top-level
valuesarray, which includes avaluesmap, which includes anothervaluesarray. Can we either elide some of this nesting (if we movemetric_typeandtypeto a higher level, this structure would only include fields named "values"), or pick more meaningful names? And out of curiosity, will the top-levelvaluesarray ever have more than one element?
Probably questions for @bnaecker.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the timeseries query endpoint and the response example in this issue. Resolve whether metric and value types can move to table level, whether the nested values fields should be renamed or removed, and whether the top-level array can contain multiple elements. Done means the response shape and its intended cardinality are agreed and documented for implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- api
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100