influxdata / influxdata/ui

DataExplorer/Dashboard/Notebooks: handling of variables in query payload.

Open
#4,691 2 comments 0 reactions 1 assignee Claimed by @wiedld View on GitHub
kind/bug team/automation
Dominant language
TypeScript
Stars
117
Forks
51
Avg merge
2d 15h
Merged PRs (30d)
4

Description

## Double use of the `v` namespace
* extern defines `option v`. Query itself may have `v={windowPeriod: x, anotherVar: y}`.
* this conflicts when we have BOTH an extern defining v, and an internal user expression defining v.
```
option v = {windowPeriod: 120000}
from(bucket: "sample_data")
|> range(start: v.timeRangeStart, stop: v.timeRangeStop)
|> filter(fn: (r) => r["_measurement"] == "airSensors")
|> filter(fn: (r) => r["_field"] == "co")
|> yield(name: "${v.windowPeriod}")
```
* extern would still need to inject `option v = {timeRangeStart: X, timeRangeStop: Y}`
* Should the user only be allowed to utilize one of these approaches?

## Not unified behaviors:
* different behavior in notebooks versus rest of application:
* notebooks injections/updates existing `option v` within the actual flux script
* Pro: can never double define
* Con: injecting runtime variables to be persisted in a flux query (e.g. exported Task)
* Dashboard and DataExplorer provides the extern. No modification of user's flux query
* Pro: are not persisting incorrectly calculated windowPeriod as a option v injected into the script
* Con: fails if the double `v` declaration

## Acceptance criteria of solution:
* same behavior across the application
* must allow some injection of outer scope (UI outside the flux editor) or variables.
* solution may include changes up/down the stack.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.