[Hawkular-dev] [inventory] Reading and querying metric type data type

[Jay Shaughnessy]

Could you maintain "type" in the JSON and support for the 
"__metric_data_type " filter for some short deprecation period?  And 
then add "metricDataType" to the json and a new metricDataType filter?   
Then we can actively update our uses of the deprecated API and anyone 
else will also have a chance to do so as well.


On 8/16/2016 11:53 AM, Lukas Krejci wrote:
> Hi all,
>
> while working on [1] I came across an incosistency in how the data type of a
> metric type (i.e. gauge, availability, counter, ...) are stored and presented.
>
> When you read a metric type using the REST API, you get something like this
> back (some fields ommitted for brevity):
>
> {
>    "path" : "/t;tnt/mt;myMetricType",
>    "unit" : "NONE",
>    "type" : "GAUGE",
>    "collectionInterval" : 0,
>    "id" : "myMetricType"
> }
>
> The metric data type is called "type" here (somewhat confusingly) and contains
> the value in upper case.
>
> If you wanted to filter by it, prior to fix to the above mentioned JIRA, you
> had to:
>
> /traversal/...;propertyName=__metric_data_type;propertyValue=gauge
>
> Notice 2 things:
> * the name of the property is different
> * the value is in lower case
>
> Now the question is how to bring order to this mess. Because the ideal fix
> will break the format of the data, I'd like to discuss this with the rest of
> the team so that we come to a compromise that will amount to the least amount
> of work for all the inventory clients.
>
> There are 2 obvious problems here:
> 1) the mismatch between the property name in the JSON output and the property
> name used when querying
> 2) the mismatch of the letter case in JSON output and queried property value
>
> For 1) I'd like rename BOTH the JSON output and queried property name to
> "metricDataType". We can't "type" because its already taken to mean the type
> of the entity and we can't use "__metric_data_type" because it's inconsistent
> with the rest of the properties.
>
> For 2) I'd like to consolidate on the upper case usage because that's the
> default Jackson serialization of the enum.
>
> Both of these (and especially 1)) can break existing clients.
>
> What would be the path of least resistance for your usecase?
>
> [1] https://issues.jboss.org/browse/HWKINVENT-192
>
> Thanks,
>