-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggestion - Identify time-column by field-name rather than value #34
Comments
Also from me a big THANK YOU for this plugin !!! I think I have the same problem. Screenshot - one query laster: Here a short screen video ... |
Thank you for the kind words, and for taking the time to post your feedback! The time detection is definitely a bit naïve at the moment. Selecting a property to use as the time column assumes a visualization that only uses one time field, such as the Graph panel. Other visualizations could potentially require several time fields, e.g. start and end time. I'm leaning towards adding a Type drop-down for each JSON Path query where you can explicitly specify how to parse the type, e.g. string, number, time. This would solve another feature request where numeric values are quoted. The issue pointed out by @PreinfalkG however is a bug and should be fairly easy to sort out in the meantime. |
Thank you for your feedback. |
Hello, first off, I'd like to thank you for this plugin 👍 . I think graphing arbitrary rows of json from an HTTP endpoint should be part of the core grafana product.
Problem
While trying to add a single-value to a stat panel, I was surprised by the automatic attribution of the type:time to my value since it met the conditions (length of 10 or 13 etc.. ). I tried working around it through the various override options in the grafana GUI but found none and resorted to modifying my data from the backend (to not be of length 10 or 13).
Suggested solution
My suggestion would be to just use the field-name "time" instead. This is how grafana natively identifies the time column, so it would make queries more portable and reduce UX surprises.
Thanks again for the plugin.
The text was updated successfully, but these errors were encountered: