Using the same parameter name across different queries does not bring over any info about the already-defined parameter. For example, if you define a dropdown list in one query and then use that same parameter name in another query, you have to input your entire dropdown list again.
You’re right that Redash doesn’t yet have global parameters. We’ve talked about this a few times in the past for things like
current user or
current time zone. But it’s not on the development schedule for now. We’d gladly review a pull request though
Since V7, you can workaround this for queries on a dashboard using Dashboard Parameter Mapping. Have you tried this?
I have, but I don’t believe that prevents having to redefine each variable within the actual query, correct?
I don’t understand the question. What do you mean by “redefine each variable”?
Sorry - parameter, not variable
Say I have a parameter called “data_environment,” which is defined in one query as a dropdown list with a few text values. If I use that same parameter name in another query, I have to again select the parameter type and redefine the text values.
Hi @jdw818, you can create a query that returns the text values for the parameter and reuse it all over your Redash host.
For instance, the following query can be used when you need a parameter for “Month”:
select * from (VALUES (1, '01 - January'), (2, '02 - February'), (3, '03 - March') , (4, '04 - April'), (5, '05 - May'), (6, '06 - June') , (7, '07 - July'), (8, '08 - August'), (9, '09 - September') , (10, '10 - October'), (11, '11 - November'), (12, '12 - December')) AS months(value, name);
Please notice that, in this case, the parameter will receive the integer value (from the “value” column). If you need just a string, you can simplify the query:
select * from (VALUES ('January'), ('February'), ('March'), ('April') , ('May'), ('June'), ('July'), ('August') , ('September'), ('October'), ('November'), ('December')) AS months(name);
Note: the syntax here is for PostgreSQL but I guess it can be easily adapted to many other databases.
Generally, yes. Dashboard parameter mapping is how you can avoid this. I just opened a bug report on GH because this doesn’t seem to work with dropdown list parameters:
Until that bug is squashed, use @agnoldo’s approach. The Query Based Dropdown List is meant for exactly your use-case. His syntax of selecting from tuples is a convenient one. You could rewrite his query with UNIONs as well (which would work in most SQLs).
SELECT 1 "value", '01 - January' "name" UNION ALL SELECT 2 "value", '02 - February' "name" UNION ALL SELECT 3 "value", '03 - March' "name" UNION ALL SELECT 4 "value", '04 - April' "name" UNION ALL SELECT 5 "value", '05 - May' "name" UNION ALL SELECT 6 "value", '06 - June' "name" UNION ALL SELECT 7 "value", '07 - July' "name" UNION ALL SELECT 8 "value", '08 - August' "name" UNION ALL SELECT 9 "value", '09 - September' "name" UNION ALL SELECT 10 "value", '10 - October' "name" UNION ALL SELECT 11 "value", '11 - November' "name" UNION ALL SELECT 12 "value", '12 - December' "name"
Ultimately we’d like to have global parameters (as mentioned above). But meanwhile this solution covers most use-cases we’ve seen.