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, Assigned: chutten)
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")]
toLifetime
when 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
•