-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Parameters Overhaul - UI/UX #2646
Comments
2644 - I love being able to simply {{ my parameters in. A button is just more mouse movement which doesn't keep up with my brain. 2642 - 'improve' date time, I think the cal wheels are just a little buggy. I thought of hacking something myself around date/time params but then realised the dropdown allows you to specify 'humantime' variables that work equally well rather than selecting dates.... It would be neat if you could splice both 'humantime' handlers for high level dates and a date selector for getting granular. I don't know if there's an ER or entry somewhere in GIT, I'm sure I saw it somewhere. The ultimate nice to have would be 'default values' for params. Dates in particular if null can make queries either invalid or needlessly ownerous on the datasources. 'Being able to specify a default date as '6 months ago' while allowing user reconfiguration and refresh would be an awesome nice to have. |
@psydone we're going to keep the type-in way to enter parameters 👍 Thanks for the valuable feedback! |
lol just as I received your message I saw the thread on github saying so... AWESOME!! |
My wishes Multiselect parameters: I would love to use parameters in queries like
This will not work currently when the parameter is a list of items. Like ('A', 'B'). Empty parameters: Also I would like to be able to leave the parameter field empty. Currently query will not run in that case. |
What about parameters backed by a python function? For instance, consider a simple country/appVersion filter. At the moment, I use the special keyword "all" that signifies all countries/app versions and use the CASE function in SQL:
That works fine most of the time, but I'd also like to be able to filter all app versions between 1.10 and 1.12. If I write "1.10-1.12" in the parameter value, I'll have to write a pretty biggish SQL expression for interpreting this edge case. While that's not a big problem by itself, if I have a dozen queries where I want this filter I'll have to copy paste this SQL expression. Moreover, when using multiple such filters the initial SQL logic is obfuscated by these multiple CASE expressions all over the place. If parameters could be backed by a python function, I could reuse this function in all queries, reduce the clutter in my original SQL and do more complicated processing in it (rather than SQL). The SQL filters would be reduced to :
|
I'm closing this one -- most of it is done and #2645 is a huge project on its own. |
Parameters in Redash hold a lot of potential. We plan to completely overhaul the implementation both on the UI/UX front and also the backend implementation to allow more varied usage scenarios.
This issue is for discussion of the UI/UX improvement of parameters. There is also this board to track the actual progress.
The plan is:
Refresh query when parameters update Refresh query when parameters update #2316Dashboard ParametersDashboard Parameters #2641Explicit “Add Parameter” Button in Query EditorExplicit “Add Parameter” Button in Query Editor #2644Improve Date/DateTime type parametersImprove Date/DateTime type parameters #2642Date Range Type ParameterDate Range Type Parameter #2643We welcome you to share your thoughts and ideas.
The text was updated successfully, but these errors were encountered: