Some parses are ambiguously ordered by nature, so tests are unduely
failing. I'm going to need to create a typeclass like ApproxEq that is
order-ivariant in some cases.
Changes in this commit:
- Put a note on scanSearch's runtime properties
- Resolve a "todo" making ScrollId a proper newtype.
- Add low level api calls for getInitialScroll and advanceScroll, with
which scanSearch is now implemented.
'scanSearch' provides a high level but pretty limited functionality. It
scans over the entire search range and appends hits into a list. There
are a few problems with this approach:
1. It uses lazy lists and O(n) appends on each page fetched. This
probably isn't a big deal for small results sets but for larger ones
this could get inefficient. Which brings me to
2. It collects all the results in memory, so in general its not suitable
for large data sets anyways.
3. The scroll window was fixed to 1 minute. That's a reasonable default
but this isn't a decision that the library can make categorically.
4. *only* scanSearch was exported, making it impossible to perform a
scrolling search if you wanted something more efficient.
This change leaves scanSearch how it is but adds getInitialScroll and
advanceScroll which can be easily used to create a
pipes/conduits/what-have-you stream of hits. The only semantic changes
are:
1. ScrollId is now a newtype as originally intended by the feature's
author.
2. MonadThrow has been introduced into the type signature for
the (AFAIK) impossible edge case of the server returning a response that
can't be parsed as an EsError.
Tests are now passing for very small sets. Tests otherwise take an
eternity. May need to manually specify instances for Query and Filter to
explicitly put in size reduction.
