Further to (2). Would it be an improvement to have a different kind of
request for a scrolling search - that way the api could exclude items that
don't make sense (e.g. aggregations, facets, etc)
On Wednesday, 18 June 2014 10:28:06 UTC+1, mooky wrote:
Many thanks Jörg.
Further
Many thanks Jörg.
Further questions/comments inline:
1. yes
Thanks,
2. facet/aggregations are not very useful while scrolling (I doubt they
even work at all) because scrolling works on shard level and aggregations
work on indices level
If they are not expected to work, would it make
Having hit a bunch of issues using scroll, I thought I better improve my
understanding of how scroll is supposed to be used (and how its not
supposed to be used).
1. Does it make sense to execute a search request with scroll, but
SearchType != SCAN?
2. Does it make sense to execute a
One more question I forgot:
Rather than looking at hits.length to know if the end of the scroll has
been reached, would it not be better to return a null scrollId when the end
of the cursor has been reached? On the surface it seems that would be
a) more intuitive
b) be the same regardless of
1. yes
2. facet/aggregations are not very useful while scrolling (I doubt they
even work at all) because scrolling works on shard level and aggregations
work on indices level
3. a scroll request takes resources. The purpose of ClearScrollRequest is
to release those resources explicitly. This is