V8 Public query params and download csv

Hi, I upgraded to v8 for getting new feature about params on public dashboards and querys.

I has some querys unpublished because I embed it on a iframe, and when they has params, the public url feature was disabled until v8.

However, when I updated to v8 and try to embed this urls, the ‘download csv’ feature has dissapeared!
The other querys, without params has no problem, and they can download as csv, but not with the new ones!

There is a bug? I got an error on my querys? Or is an expected result?

Thanks

1 Like

What you describe is the expected behavior. Were you able to download CSV results of parameterized queries from public dashboards in V7?

I know that in V7 I can’t use parameterized queries on public dashboards.

So I updated to V8. In V8 I can use it on public dashboards and public querys sucessfully. The problem Is that there are no button for download as csv when I use parameterized queries and make it public. Maybe with an example will be better. Both images are on V8. Two public querys inside an iframe. Both on same redash instance and same code for embed


On this query, We can download the data


On this one, We can’t download the data. As you can see, on the upper, there is a parameter.

Yes, not being able to download the dataset is known limitation at the moment. The reason being is that we don’t have a direct URL for the query results we can provide the browser. For rendering the results in the browser we use a hack/workaround: if no cached result is available, we trigger a refresh, poll for its status, and when it’s finished we try to pull a cached result with the hope it will be there.

I wonder if it’s safe to use the same approach for the download URL? I.e., after the refresh is finished render the URL. It might break in unexpected scenarios, like when the page was left open for several days and the cached result was deleted.

1 Like

In that case we could serve a page that says “This download link has expired”.

1 Like

Yes, I think that it will be a minor problem. It only happen in specific cases as arikfr says, and in most cases will be abailable.

Is there any ongoing effort to fix this ? If not will be happy to help, this happens to be a real important use case for me :sweat_smile:

I gave it some more thought and it actually a bigger problem than I initially described: cached results get removed after X days (X is configurable) after retrieval, so if you happened to load it in X - (few minutes) then it will be available, but shortly after that be removed and not available for download.

But I realized there is another solution: we can generate the download file in the browser. We used to do it in the past using data URI, but stopped because it had size limits and some other issues. But looks like today we can use a Blob, which has much higher size limits.

We can utilize FileSaver.js, although it’s possible we might not need it as we target modern browsers.

I would start with implementing support for only CSV as a first step and maybe in the future add support for Excel as well.

A nice side effect of this is the ability to allow downloading the filtered data set.

@udaykrishna is this something you might be interested in helping with?

1 Like

@arikfr won’t using browser blobs make the tab un-responsive on mid-low-end devices? plus there will be nothing an infra/devops guy could do to fix this. Right now I have a temp hack in place which utilizes a browser blob for our use case and i can see it failing is when a user tries downloading a large data-set. if you think that its not going to be a problem then, I can surely get started on this.

Interesting. Can you share what size was this large data-set? And what would be mid-low-end device by this definition?

can add a button for show all table data on pagination? download data through HTML table.

The issue here is that larger data sets will cripple a browser as it tries to draw all the HTML table nodes. Likewise, copy-paste of a table that size won’t perform well even on high spec PCs.

To test out how bad the cache-miss issue might be, I removed the “ng-if=”!$ctrl.public"" from the widget.html and found the menu appears as expected but it was interesting to find that even queries which I had just run a second ago fail to download as CSV. I’m not sure how to explain this given the other comments on this page.

Update: I see the URL is https://redash-dev.aveadesk.com/api/queries/2/results/undefined.csv which explains the download failure.

For anyone else who might try this, the bigger problem will be that your user might not be authenticated to access the csv link. A new type of link with a Key will need to be generated.

Don’t exactly remember the data size, but it usually happens on windows laptops with 4G RAM or less.

I meant devices with low RAM probably got nothing to do with the device class as its relative.
Never got any complaints but was thinking that people accessing redash on tablet/mobile devices might run into similar issues as well. This is a pretty rare occurrence for us though as we usually don’t use redash to download large datasets.

Not sure if related but queries run by users without edit access to a query don’t update cache. could this be a likely cause ?

Fixing the permission issue and triggering a rerun could be an ideal longterm solution but using the browser blob could be a decent alternative until the permissions part is figured out and implemented