1

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.

2

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 :smiley:

Since V7, you can workaround this for queries on a dashboard using Dashboard Parameter Mapping. Have you tried this?

3

I have, but I don’t believe that prevents having to redefine each variable within the actual query, correct?

4

I don’t understand the question. What do you mean by “redefine each variable”?

5

Sorry - parameter, not variable :slight_smile:

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.

6

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.

7

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.