Allow direct download of small (<=1K) recordsets

[jotegui]

This was implemented in the portal-centered way of doing things, because a search would return the number of records available and, based on that, the dowload service would decide to create the download directly or launch the asynchronous service. However, calling the download API doesn't precalculate this value and, therefore, all downloads are performed asynchronously.

This feature requires having a good, greatly optimized count service (#3), since it would involve calling such a service first to calculate the records to download and then call the download service itself based on these results.

[jotegui]

A workaround has been deployed. There is a new parameter for download calls, r, which indicates the expected number of records to return. If that value is provided and is less than 1K (current threshold for small/large downloads), then the direct download code is triggered. Otherwise, the task is enqueued.

This should not be a permanent solution, though. Ideally, we should come up with a way of efficiently counting recordsets and link the download method to it

[tucotuco]

Where do you expect the value of r to come from?

On Tue, May 24, 2016 at 7:43 AM, Javier Otegui [email protected]
wrote:

A workaround has been deployed. There is a new parameter for download
calls, r, which indicates the expected number of records to return. If
that value is provided and is less than 1K (current threshold for
small/large downloads), then the direct download code is triggered.
Otherwise, the task is enqueued.

This should not be a permanent solution, though. Ideally, we should come
up with a way of efficiently counting recordsets and link the download
method to it

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#5 (comment)

[jotegui]

In the case of portal downloads, it comes from the previous "associated"
search. In the case of direct downloads, I was thinking it could come from
that utopian efficient count method ;)

However, with the solution outlined in issue #3, things might be a bit
different...

Javier Otegui
http http://www.jotegui.com:// http://www.jotegui.comwww.jotegui.com
Where do you expect the value of r to come from?

On Tue, May 24, 2016 at 7:43 AM, Javier Otegui [email protected]
wrote:

A workaround has been deployed. There is a new parameter for download
calls, r, which indicates the expected number of records to return. If
that value is provided and is less than 1K (current threshold for
small/large downloads), then the direct download code is triggered.
Otherwise, the task is enqueued.

This should not be a permanent solution, though. Ideally, we should come
up with a way of efficiently counting recordsets and link the download
method to it

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#5 (comment)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#5 (comment)