Make all exported metrics definition types more convenient for use with serde
Categories
(Data Platform and Tools :: Glean: SDK, enhancement, P2)
Tracking
(Not tracked)
People
(Reporter: chutten|PTO, Assigned: chutten|PTO)
References
Details
Attachments
(1 file)
It would be convenient for FOG if the Glean SDK would make all of CommonMetricData Deserialize so metric definition information could be parsed from a string (for the purposes of dynamic registration of metrics (JOG)).
With the power of serde remote derivation JOG may be able to get CommonMetricData to work if only Lifetime is Deserialize, but that would be less convenient.
JOG doesn't need Serialize since the serialization for artefact builds will happen at build time in a Python environment, not a Rust one. However, if we're looking ahead to Dynamic Telemetry (where definition information comes over the wire) then it might be beneficial to have Serialize as well.
What might be noteworthy is that, already, quite a few other exported metric definition types (TimeUnit, MemoryUnit, HistogramType) are convenient for use with serde, so really we're just bringing the rest of these types up to standard : )
| Assignee | ||
Comment 1•3 years ago
|
||
Jan-Erik, what's your opinion on me taking the most-convenient-for-FOG route and "just" deriving Serialize and Deserialize for CommonMetricData (which implies Lifetime)?
| Assignee | ||
Updated•3 years ago
|
Comment 2•3 years ago
|
||
Go for it. You should probably add #[serde(rename_all = "lowercase")] to Lifetime when deriving Serialize.
Updated•3 years ago
|
| Assignee | ||
Comment 3•3 years ago
|
||
(In reply to Jan-Erik Rediger [:janerik] from comment #2)
Go for it. You should probably add
#[serde(rename_all = "lowercase")]toLifetimewhen derivingSerialize.
I hope that's all it needs. I added that directive for the Deserialize remote derivation I was trying to use for an all-in-JOG impl and it wasn't enough : |
Comment 4•3 years ago
|
||
| Assignee | ||
Comment 5•3 years ago
|
||
Description
•