Raise error when multiple IPC streams are received #23
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pmm-motif
force-pushed
the
arrow-scan-multi-ipcs
branch
from
503d783 to
9981d03
Compare
pmm-motif
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It's perhaps an obscure case, but I had issues with using Node.js DuckDB library with
register_buffer()when multiple Arrow Table streams were passed as an argument. This use-case somewhat works with DuckDB WASM (it's possible to append additional Arrow Tables) so I initially thought it's some sort of bug.However, as I was investigating this, I realized that I'm probably using it incorrectly in the first place (though it's not clearly documented). I.e. when multiple IPC Buffers are provided, they must be all part of the same Arrow IPC Stream.
The underlying Arrow IPC Reader seems to be silently stopping when getting into EOS. What I'm proposing in this PR is detecting when more messages are available after getting EOS and throwing an exception rather than just silently consuming these.
It's plausible that I'm missing something or that this check should go Apache Arrow instead. Curious of your thoughts on this
Thank you!