Thanks for the feedback Frank.
On 04/02/15 02:23, Frank Ch. Eigler wrote:
...
A baby step could be just a documentation change, namely to inform
pmwebapi users that the returned "name" field is -a- name for the
PMID, rather than -the- name or -all- names. (The pmwebapi.3 man page
doesn't even go into detail and calls that field self-explanatory.)
I'll do that.
A possible step would be to pass back all names for pmid-metadata, one
could add a JSON vector subfield like
"names": ["foo.bar", "foo.bar2"]
to the /pmapi/NNNNN/_metric query.
A likely necessary step would be to tweak the /_fetch code, so that
the result "name":"NAME*" fields match up with the /_fetch?name=NAME
requests. This would mean teaching pmwebapi_respond_metric_fetch() to
store not just resolved "pmID *metrics;" but a vector of pre-resolved
"metric-names". I can give that a go if you like.
I am not sure it really worth it, until we have a real use case outside
the sample PMDA.
My goal was to make the core functionality robust after allowing
duplicate PMNS names by default, and I think the two pieces I've found
issues with can probably stay unchanged for the time being.
In addition to the documentation change I might add a comment in the
code (based on your email) so (a) the limitation is noted, and (b) the
possible fix is not lost in the email archive bog.
Thanks again.
|