Skip to content
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

Closed
chnn opened this issue Mar 20, 2019 · 5 comments
Closed

Add ability to specify absolute time range in v1.tagKeys, v1.tagValues #1071

chnn opened this issue Mar 20, 2019 · 5 comments

Comments

@chnn
Copy link
Contributor

chnn commented Mar 20, 2019

I would like to be able to use an absolute time range when calling the v1.tagKeys and v1.tagValues functions.

Something like this:

import "influxdata/influxdb/v1"

v1.tagKeys(bucket: "telegraf", start: 2019-01-01, stop: 2019-06-01)

I still want to be able to use the function as it works currently:

import "influxdata/influxdb/v1"

v1.tagKeys(bucket: "telegraf", start: -1d)

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:

tagKeys = (bucket, predicate=(r) => true, start=-30d, stop=0d) =>
    from(bucket: bucket)
        |> range(start: start, stop: stop)
        |> filter(fn: predicate)
        |> keys()
        |> keep(columns: ["_value"])

tagKeys(bucket: "telegraf", start: 2019-01-01, stop: 2019-06-01)
failed to compile query: type error 9:1-9:47: duration != time
@nathanielc
Copy link
Contributor

@chnn Your change looks correct but that we are running into a limitation of the current Flux type system. The plan is to treat duration literals as polymorphic, meaning they can be either a time or a duration. See #1073 Until that is done this will not work as expected.

@aanthony1243
Copy link
Contributor

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.

@rbetts rbetts removed the blocker label Apr 26, 2019
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
@R-Studio
Copy link

Any news on this?

@R-Studio
Copy link

Following workaround is working for me, but it is not very sexy:

from(bucket: "<YOUR_BUCKET>")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => 
    r._measurement == "<YOUR_MEASUREMENT>"
  )
  |> keyValues(keyColumns: ["host"])
  |> group()
  |> keep(columns: ["host"])
  |> distinct(column: "host")

host = is the field I want in my Grafana template variable

I hope this helps someone. :-)

Copy link

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
Projects
None yet
Development

No branches or pull requests

6 participants