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
Query versioning #25
Comments
👍 This would be great, and the lack of it was one of the key cons on my list of deciding whether or not to adopt redash. |
+1 |
Along the same lines, comparing results between queries could be very useful too. A "Compared to previous version" tab next to the "Results" tab would be neat-o. I often export results to CSV files and compare them with daff. |
Daff has a JS library, so it could perhaps even be integrated directly into the frontend. |
@tsibley I'm planning to give access to past query results (they are stored anyway). Will keep daff in mind when it happens. |
I was wondering if would not be better change the approach. In my conception we can use GitHub as a "queries source". Basically it would work as follows: In Redash settings we would have to set up:
In the UI, on the query creation page, we would have a field where we would put the path to the query Our handler will hit the GitHub servers at I even started to make a prototype, but not finished it. I think we could save a good development time with this idea and get the queries versioning working 😄 |
@WesleyBatista It's a good idea, and one I've sketched out on paper for working with a local clone with bidirectional sync rather than assuming Github. I definitely like the idea of being able to look at query history in Git with my normal tools. At the same time, such a change would require a substantial rework of the current backing datastore for queries and query-related data, and this might be prohibitive to a short-term fix. There's also nothing in particular that precludes doing a pluggable, Git-based query store later even if the project implements a non-Git query versioning scheme first for the short term. |
Using Git definitely crossed my mind and I even wrote a script that exports all queries as files to a folder that is managed with Git. But the challenge for this feature is not only with how to store queries but also in building the appropriate UI, which using Git doesn't solve. I think the right way to go will be to have an optional Git store, but not mandatory. |
Totally agree with you guys! This can not be considered as a final solution. Surely it is an idea to be worked. But I was wondering about the requirements to get the idea working. What I thought til now was:
We can hide the feature on the early steps requiring to set REDASH_ENABLE_EXTERNAL_QUERY_SOURCE to True on the environment. To store the "query url" we can create a migration to add a 'options' column on As next steps we could think in improve the UI. The final one could be something more like a modal, navigating through the directories retrieved from the repo. Maybe add support to gists too... I dont know, just wondering. So the tech debits that I found:
Please, sorry if I am being too ingenuous and missed something (I probably did it). What do you guys think? |
And what do you think about the |
@WesleyBatista I think an external query source likely wants to be more general than "fetch from a URL". Just like there are different data sources, there should probably be different query providers you can plug in and use. One provider might fetch from a URL, one from git, and another from a database itself. One way to design it might be to have the default query provider be a database provider pointed at re:dash's own database. I expect, as you identified as a possibility, that any solution would want to cache query sources somewhere and have a means for updating/invalidating that cache. The benefit of using the current A design that's appealing to me (and common in many areas) is something like a cascading provider list where, when it comes time to update a query source, each provider is tried in turn to provide the query source until one is able to. When it is, the query source is cached and the cache provider will be able to return it sooner the next time as long as it hasn't expired. |
hello ... I would give the redash project development |
any news about this features ? |
Any new about the? It would be a great option to have and would make Redash so compelling. Also instead of limiting this to just Github, it would be preferable to open this to any generic Git repo server so that any self-hosted, or SAS services Git servers out there can be used (over SSH)-- and even allow a localhost repos on a Redash instance... |
Any updates here. |
Nothing to share at this time. Later this year we plan to have a more transparent roadmap / engagement with contributors. We'll announce that on the user forum. |
Any update here? |
Not at this time. |
I saw that mozilla#149 was merged, that adds query versioning, or? If so which version of redash will this be included in? I don't see it in the version we are using. |
Mozilla haven't upstreamed this to the primary redash repository so there's no roadmap to include their change here. |
Are the query versions already stored in the database so I can access them manually? |
Create preview docker image on merge to master
Are there any more updates on this? This would be a very useful feature to have. |
The text was updated successfully, but these errors were encountered: