-
Notifications
You must be signed in to change notification settings - Fork 153
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
Add ability to specify absolute time range in v1.tagKeys, v1.tagValues #1071
Labels
Comments
the real issue here is the default arguments. by setting the defaults as durations, our type system can't handle if you then call the function with times. |
chnn
added a commit
to influxdata/influxdb
that referenced
this issue
Apr 26, 2019
Currently, slight changes in the form of a Flux metaquery can have drastic performance implications. To solve this issue, the Flux language provides helper metaquery functions such as `v1.tagKeys` and `v1.tagValues` which are guaranteed to be as fast as possible. In #12791, we switched away from using the `v1.tagKeys` and `v1.tagValues` functions in the query builder to their underlying Flux implementations in order to implement a UI feature. While the new metaqueries used in the query builder were still optimized at the time, the Flux language has since changed and this is no longer the case. In addition, the metaqueries in the UI no longer hit the same code-path in Flux which has exposed a logic bug in the queries. So when executed, the metaqueries return the following error: schema collision detected: column ""_value"" is both of type float and int This PR updates the metaqueries used in the query builder to their [currently optimized form][0]. The long term solution is to address [this][1] issue and then switch back to using the safer `v1.tagKeys` and `v1.tagValues` functions directly. [0]: https://github.com/influxdata/flux/blob/master/stdlib/influxdata/influxdb/v1/v1.flux [1]: influxdata/flux#1071 Closes #13660
chnn
added a commit
to influxdata/influxdb
that referenced
this issue
Apr 26, 2019
Currently, slight changes in the form of a Flux metaquery can have drastic performance implications. To solve this issue, the Flux language provides helper metaquery functions such as `v1.tagKeys` and `v1.tagValues` which are guaranteed to be as fast as possible. In #12791, we switched away from using the `v1.tagKeys` and `v1.tagValues` functions in the query builder to their underlying Flux implementations in order to implement a UI feature. While the new metaqueries used in the query builder were still optimized at the time, the Flux language has since changed and this is no longer the case. In addition, the metaqueries in the UI no longer hit the same code-path in Flux which has exposed a logic bug in the queries. So when executed, the metaqueries return the following error: schema collision detected: column ""_value"" is both of type float and int This PR updates the metaqueries used in the query builder to their [currently optimized form][0]. The long term solution is to address [this][1] issue and then switch back to using the safer `v1.tagKeys` and `v1.tagValues` functions directly. [0]: https://github.com/influxdata/flux/blob/master/stdlib/influxdata/influxdb/v1/v1.flux [1]: influxdata/flux#1071 Closes #13660
Any news on this? |
Following workaround is working for me, but it is not very sexy:
host = is the field I want in my Grafana template variable I hope this helps someone. :-) |
This was referenced Jan 29, 2021
This issue has had no recent activity and will be closed soon. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
I would like to be able to use an absolute time range when calling the
v1.tagKeys
andv1.tagValues
functions.Something like this:
I still want to be able to use the function as it works currently:
I was going to update the functions in the stdlib, but ran into an issue. I don't know how to make these functions accept both a time or a duration as an argument:
The text was updated successfully, but these errors were encountered: