* try to fix the types again
* fix test (breaking)
* [breaking] only support object format for parquetReadObjects and parquetQuery
* remove internal types
* remove redundant test
* override __index__ with original data if present
Also: add comments to explain special cases.
* remove the need to slice arrays
* loosen the types to avoid code duplication
* always write the index, because the results should be consistent
* Revert "always write the index, because the results should be consistent"
This reverts commit fd4e3060674fa6e81bd32fc894d7c366103e004a.
It silently provided an empty array, instead of throwing an Error, or
providing the data in rowFormat="object".
Here, I (silently) force the rowFormat to "object".
* Parquet Query Planner: plan byte ranges, pre-fetch in parallel.
- parquetPlan() that returns lists of byte ranges to fetch.
- prefetchAsyncBuffer() pre-fetches all byte ranges in parallel.
throws exception if non-pre-fetched slice is requested later.
* types must be the first element. Spotted by publint.dev
* Package test for exports
* Test package.json for string exports
---------
Co-authored-by: Kenny Daniel <platypii@gmail.com>
* pass custom fetch function to utils
it can be used to implement retry logic.
* Update src/utils.js
Co-authored-by: Kenny Daniel <platypii@gmail.com>
---------
Co-authored-by: Kenny Daniel <platypii@gmail.com>
Do this by passing rowGroupStart and rowGroupEnd for the rows to
fetch within a rowgroup. If a page is outside those bounds, we can
skip the page. Replaces rowLimit.
* Support endpoints that don't support range requests in asyncBufferFromUrl
Before this commit asyncBufferFromUrl assumes that the body of whatever
successful response it gets is equivalent to the range it requested. If
the origin server does not support HTTP range requests then this
assumption is usually wrong and will lead to parsing failures.
This commit changes asyncBufferFromUrl to change its behaviour slightly
based on the status code in the response:
- if 200 then we got the whole parquet file as the response. Save it and
use the resulting ArrayBuffer to serve all future slice calls.
- if 206 then we got a range response and we can just return that.
I have also included some test cases to ensure that such responses are
handled correctly and also tweaked other existing mocks to also include
the relevant status code.
* Fix all lint warnings
* replace switch with if-else
