GH-44366: [Python][Acero] RecordBatch.filter on expression raises error if result set is empty - #46057
Conversation
|
Thanks for opening a pull request! If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project. Then could you also rename the pull request title in the following format? or See also: |
|
cc @wgtmac |
|
|
|
Thanks for the fix! It looks reasonable to me. However, I'm not familiar with the convention here. Perhaps @jorisvandenbossche @pitrou can help. |
|
Thanks for the PR! |
AlenkaF
left a comment
There was a problem hiding this comment.
Thank you for contributing a fix for this.
I have one comment that will need a small change, otherwise the changes look good!
|
Thank you all so much for the guidance! |
|
|
|
After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit b1618e0. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 7 possible false positives for unstable benchmarks that are known to sometimes produce them. |
…es error if result set is empty (apache#46057) ### Rationale for this change When filtering a RecordBatch using an expression that results in zero matching rows, an IndexError was raised due to an attempt to access the first batch of an empty result. This change ensures that such cases are handled gracefully by returning an empty RecordBatch with the correct schema. ### What changes are included in this PR? Fixed a bug in _filter_table where filtering all rows from a RecordBatch would raise an IndexError. Added a helper function _empty_record_batch_from_schema to construct an empty RecordBatch with the correct schema. ### Are these changes tested? Yes, the behavior was verified manually. Let me know if you'd like a dedicated test case added to the test suite. ### Are there any user-facing changes? No changes to public APIs. The fix ensures more robust handling of edge cases internally. - Github issue: apache#44366 * GitHub Issue: apache#44366 Authored-by: Koen Vossen <info@koenvossen.nl> Signed-off-by: Raúl Cumplido <raulcumplido@gmail.com>
|
@github-actions crossbow submit -g python |
|
Revision: b5ef330 Submitted crossbow builds: ursacomputing/crossbow @ actions-85876e4ee6 |
|
I noticed this change caused a very minor regression with the example-python-minimal-build-ubuntu-venv and example-python-minimal-build-fedora-conda jobs. You can see the failing test here: From what I can tell, the added code here ends up referencing code from the pyarrow.acero module. However, it is possible to have a pyarrow configuration where compute is enabled but acero is not. The tests are failing in that case |
|
I may have mistakenly suggested moving the tests to |
|
or mark them as |
True! I already opened a PR: #46175. Can change to adding a mark if there will be a preference for it. |
…ndexError RecordBatch.filter(Expression) raises IndexError on PyArrow 17-20 when the result has zero rows (fixed upstream in apache/arrow#46057). Replace the try/except approach with the Table-based workaround that avoids the bug, consistent with the pattern already used for the non-positional- deletes path. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Rationale for this change
When filtering a RecordBatch using an expression that results in zero matching rows, an IndexError was raised due to an attempt to access the first batch of an empty result. This change ensures that such cases are handled gracefully by returning an empty RecordBatch with the correct schema.
What changes are included in this PR?
Fixed a bug in _filter_table where filtering all rows from a RecordBatch would raise an IndexError.
Added a helper function _empty_record_batch_from_schema to construct an empty RecordBatch with the correct schema.
Are these changes tested?
Yes, the behavior was verified manually. Let me know if you'd like a dedicated test case added to the test suite.
Are there any user-facing changes?
No changes to public APIs. The fix ensures more robust handling of edge cases internally.