Closed AdrianWestphal closed 5 months ago
I had the same problem, after upgrading the big query plugin. Is there a reason why non-string values are not supported as return value for query variables?
I was able to reproduce the issue. We need to transform the query response that we got back in https://github.com/grafana/google-bigquery-datasource/blob/main/src/datasource.ts#L38 to the following format:
[{ text: value }]
hi, in general grafana prefers to have strings as these values, see the documentation at https://grafana.com/docs/grafana/latest/dashboards/variables/add-template-variables/#add-a-query-variable
" Query variables are generally only supported for strings. If your query returns numbers or any other data type, you might need to convert them to strings in order to use them as variables. "
with bigquery you can use the CAST(numericField AS STRING)
construct to convert to string.
is there a situation where this is not possible?
hi, as we got no response here, we are closing the issue. we can reopen it when we get the necessary information. thanks!
Title:
Error in Grafana BigQuery Datasource Panel 1.4.1 When Using INT Variable: "Couldn't find any field of type string in the results"
Environment:
Description:
When using Grafana BigQuery datasource panel version 1.4.1, an error occurs when a BigQuery variable returning an integer is utilized. The error message displayed is: "Templating [Variable_name] Error updating options: Couldn't find any field of type string in the results." This behavior is specific to version 1.4.1, as the same operation works correctly in version 1.2.3.
Steps to Reproduce:
SELECT 1
.Expected Behavior:
The BigQuery datasource panel should correctly handle variables that return integers without producing an error, as it does in version 1.2.3.
Actual Behavior:
In Grafana BigQuery datasource panel version 1.4.1, using a BigQuery variable that returns an integer results in an error: "Templating [Variable_name] Error updating options: Couldn't find any field of type string in the results." Notably, the issue does not occur in version 1.2.3 and is circumvented when using
SELECT "1"
(returning the integer as a string).Additional Information:
SELECT "1"
), the error does not occur.Potential Solutions or Suggestions: