You are viewing a plain text version of this content. The canonical link for it is here.
Posted to github@arrow.apache.org by "PNHD (via GitHub)" <gi...@apache.org> on 2026/09/25 02:26:55 UTC
[PR] GH-471: Fix ListView reader iteration bounds [arrow-java]
PNHD opened a new pull request, #1310:
URL: https://github.com/apache/arrow-java/pull/1310
## What's Changed
Fix `UnionListViewReader` and `UnionLargeListViewReader` iteration so non-empty
ListView values terminate after exactly the declared number of elements.
The previous `next()` condition compared `currentOffset` against
`currentOffset + size`, which stays true for positive sizes as the reader
advances. The readers now track the number of remaining elements independently,
which also preserves correct iteration for lists whose child data starts at a
non-zero offset.
Add regression coverage for non-empty `copyFrom`, non-zero offsets, exhaustion
and repeated exhaustion, position reset, empty ranges, direct
`UnionLargeListViewReader` iteration, and indexed reads.
PR #1136 changes `setPosition()` in these readers for a separate empty-vector
bounds issue. It does not fix this iteration bug; if it lands first, this fix
can preserve its validation and initialize the remaining-element state after
position setup.
Closes #471.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] GH-471: Fix ListView reader iteration bounds [arrow-java]
Posted by "jbonofre (via GitHub)" <gi...@apache.org>.
jbonofre merged PR #1310:
URL: https://github.com/apache/arrow-java/pull/1310
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] GH-471: Fix ListView reader iteration bounds [arrow-java]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #1310:
URL: https://github.com/apache/arrow-java/pull/1310#issuecomment-5825677205
<!-- label_helper_comment -->
Thank you for opening a pull request!
Please label the PR with one or more of:
- bug-fix
- chore
- dependencies
- documentation
- enhancement
Also, add the 'breaking-change' label if appropriate.
See [CONTRIBUTING.md](https://github.com/apache/arrow-java/blob/main/CONTRIBUTING.md) for details.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] GH-471: Fix ListView reader iteration bounds [arrow-java]
Posted by "jbonofre (via GitHub)" <gi...@apache.org>.
jbonofre commented on code in PR #1310:
URL: https://github.com/apache/arrow-java/pull/1310#discussion_r4171539905
##########
vector/src/test/java/org/apache/arrow/vector/TestListViewVector.java:
##########
@@ -142,6 +144,69 @@ public void testBasicListViewVector() {
}
}
+ @Test
+ public void testCopyFromNonEmptyListView() {
Review Comment:
Could you extend the coverage a bit here? Two cases would pin down #471:
- the exact repro from the issue (non-nullable child, source built with `startNewValue`/`endValue`, 10 elements)
- a multi-row copy, rows copied in order, that includes a null row and an empty row
##########
vector/src/main/java/org/apache/arrow/vector/complex/impl/UnionListViewReader.java:
##########
@@ -97,12 +100,10 @@ public int size() {
@Override
public boolean next() {
- // Here, the currentOffSet keeps track of the current position in the vector inside the list at
- // set position.
- // And, size keeps track of the elements count in the list, so to make sure we traverse
- // the full list, we need to check if the currentOffset is less than the currentOffset + size
- if (currentOffset < currentOffset + size) {
+ // Yield exactly the element count stored with this list view, beginning at its stored offset.
+ if (remaining > 0) {
Review Comment:
With the bound in place, `read(int index, UnionHolder holder)` above now stops at the end of the view, but it still ignores the result of `next()`. For `index >= size` the holder ends up on the last element of the view with `isSet = 1`, and for an empty view on whatever the child reader was last positioned on.
`UnionListReader.read` has the same loop, so this isn't new here and I won't block on it. If you want to tighten it in both readers, something like:
```java
boolean found = true;
for (int i = -1; i < index && found; i++) {
found = next();
}
holder.reader = data.getReader();
holder.isSet = found && data.getReader().isSet() ? 1 : 0;
```
Either way, a test for the out-of-range and empty-view cases would be good: `testReaderIteratesListViewRangeAndResets` only covers an in-range index.
##########
vector/src/test/java/org/apache/arrow/vector/TestLargeListViewVector.java:
##########
@@ -2230,6 +2231,38 @@ public void testRangeChildVector2() {
}
}
+ @Test
+ public void testDirectReaderIteratesLargeListViewRange() {
+ try (LargeListViewVector largeListViewVector =
+ LargeListViewVector.empty("largelistview", allocator)) {
+ largeListViewVector.allocateNew();
+ FieldType fieldType = new FieldType(true, new ArrowType.Int(32, true), null, null);
+ largeListViewVector.initializeChildrenFromFields(
+ Collections.singletonList(new Field("child-vector", fieldType, null)));
+ IntVector childVector = (IntVector) largeListViewVector.getDataVector();
+ childVector.allocateNew(5);
+ for (int i = 0; i < 5; i++) {
+ childVector.set(i, 10 + i);
+ }
+ childVector.setValueCount(5);
+ largeListViewVector.setValidity(0, 1);
+ largeListViewVector.setOffset(0, 2);
+ largeListViewVector.setSize(0, 3);
+ largeListViewVector.setValueCount(1);
+
+ UnionLargeListViewReader reader = new UnionLargeListViewReader(largeListViewVector);
Review Comment:
The reader has to be built by hand here because `LargeListViewVector.getReader()`, `getReaderImpl()` and `copyFrom()` still throw `UnsupportedOperationException`, so nothing in production reaches the Large half of this fix yet. That's fine for this PR, but could you say so in the description?
While you are in `UnionLargeListViewReader`: `getMinorType()` returns `MinorType.LISTVIEW`. It should be `MinorType.LARGELISTVIEW` imho.
##########
vector/src/test/java/org/apache/arrow/vector/TestListViewVector.java:
##########
@@ -142,6 +144,69 @@ public void testBasicListViewVector() {
}
}
+ @Test
+ public void testCopyFromNonEmptyListView() {
+ try (ListViewVector inVector = ListViewVector.empty("input", allocator);
+ ListViewVector outVector = ListViewVector.empty("output", allocator)) {
+ UnionListViewWriter writer = inVector.getWriter();
+ writer.allocate();
+ writer.setPosition(0);
+ writeIntValues(writer, new int[] {10, 20});
+ writer.setValueCount(1);
+
+ outVector.allocateNew();
+ outVector.copyFrom(0, 0, inVector);
Review Comment:
This passes because the reader is first obtained inside `copyFrom`, after the writes. If `inVector.getReader()` is called before `writeIntValues(...)`, the copy produces `[null, null]`: the cached `UnionListViewReader` keeps its original `data` vector, because `ListViewVector.invalidateReader()` only clears `reader`, whereas `ListVector.invalidateReader()` also clears `fieldReader`.
This predates your changes, but it is a one-line fix and the easiest way to still get wrong data out of a flat `copyFrom`.
Would you mind including it here with a test? Otherwise I'm fine with a follow-up issue.
##########
vector/src/main/java/org/apache/arrow/vector/complex/impl/UnionListViewReader.java:
##########
@@ -31,6 +31,7 @@ public class UnionListViewReader extends AbstractFieldReader {
private final ValueVector data;
private int currentOffset;
private int size;
+ private int remaining;
Review Comment:
Nit: #471 points out that the approach differs from `UnionListReader`. Mirroring its `currentOffset`/`maxOffset` pair would keep the readers aligned and drop the extra decrement:
```java
// setPosition
maxOffset = currentOffset + size;
// next
if (currentOffset < maxOffset) {
data.getReader().setPosition(currentOffset++);
return true;
}
return false;
```
Same in `UnionLargeListViewReader`, where `checkedCastToiInt(currentOffset++)` and its import could also go, since `currentOffset` is already an `int`.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org