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
When we originally wrote oximeter, we supported the bare minimum of data types to streamline prototyping. We should really support more integer types. This should be a pretty mechanical change that adds, for each type:
A new oximeter::FieldType variant
A new oximeter::DatumType variant
A new oximeter::Datum variant
Possibly cumulative types for these, although that is probably only reasonable for the widest types
Possibly implement histogram support for these new integer types
New model types, oximeter_db::model::Db{Datum,Field}Type and field / measurement row types
The most important type to actually support is u64. We're currently limited to i64, which is really huge but technically not big enough to support some values (e.g., the kstats for bytes received on a datalink are technically a u64). But given how mechanical this all should be, I'd also argue for adding pretty much all the integral types.
The text was updated successfully, but these errors were encountered:
When we originally wrote
oximeter
, we supported the bare minimum of data types to streamline prototyping. We should really support more integer types. This should be a pretty mechanical change that adds, for each type:oximeter::FieldType
variantoximeter::DatumType
variantoximeter::Datum
variantoximeter_db::model::Db{Datum,Field}Type
and field / measurement row typesThe most important type to actually support is
u64
. We're currently limited toi64
, which is really huge but technically not big enough to support some values (e.g., the kstats for bytes received on a datalink are technically au64
). But given how mechanical this all should be, I'd also argue for adding pretty much all the integral types.The text was updated successfully, but these errors were encountered: