-
Notifications
You must be signed in to change notification settings - Fork 811
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make slice work for nested types #389
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,13 +26,10 @@ pub(super) fn build_extend(array: &ArrayData) -> Extend { | |
index: usize, | ||
start: usize, | ||
len: usize| { | ||
mutable.child_data.iter_mut().for_each(|child| { | ||
child.extend( | ||
index, | ||
array.offset() + start, | ||
array.offset() + start + len, | ||
) | ||
}) | ||
mutable | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This reverses 9f96561 |
||
.child_data | ||
.iter_mut() | ||
.for_each(|child| child.extend(index, start, start + len)) | ||
}, | ||
) | ||
} else { | ||
|
@@ -41,7 +38,7 @@ pub(super) fn build_extend(array: &ArrayData) -> Extend { | |
index: usize, | ||
start: usize, | ||
len: usize| { | ||
(array.offset() + start..array.offset() + start + len).for_each(|i| { | ||
(start..start + len).for_each(|i| { | ||
if array.is_valid(i) { | ||
mutable | ||
.child_data | ||
|
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jhorstmann @jorgecarleitao the problem was here. We take
data
which has children and their own offsets, then slice that data correctly to populateboxed_fields
, but then we still use thedata
with the child arrays that aren't offset.The result's that the struct is correct when looking at it through
boxed_fields
(e.g. the print utility uses this), but once you need to do anything withdata
, it's as if the child values were never sliced.The lightbulb turned on while i was trying to figure out why a test for #491 was failing.
There's a change that @bjchambers authored (9f96561) which addressed the child offsets, but my tests were failing because I needed to revert what they did.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to make sense -- my main interest was in getting the tests I added (concat on sliced struct arrays) to pass because I had run into problems with that. It seems like the tests are still here and passing, and it sounds like this may be more robust as well (addressing other issues I've hit when slicing
StructArray
such as the mentioned equality issues).For my own curiosity -- If I understand correctly, slicing the child data doesn't actually copy the data, but just creates a reference to the same data with different offsets, so this shouldn't affect performance significantly, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's correct. I relied on your tests to verify that my changes make sense.
Yes. The cost should be negligible as we're cloning a bunch of arcs individually instead of all at once