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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
