Skip to content

Conversation

@sdf-jkl
Copy link
Contributor

@sdf-jkl sdf-jkl commented Sep 16, 2025

Which issue does this PR close?

Rationale for this change

We should be able to read lists using variant_get

What changes are included in this PR?

Are these changes tested?

I'm trying to start with some basic tests to do some TDD.

Are there any user-facing changes?

Copy link
Contributor

@scovich scovich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a couple comments that are hopefully helpful.

Also, we should (eventually) support nesting -- arrays and structs inside arrays.
Let's get simple lists of primitives working first, tho!

Comment on lines 1100 to 1103
let main_struct = crate::variant_array::StructArrayBuilder::new()
.with_field("metadata", Arc::new(metadata_array))
.with_field("value", Arc::new(value_array))
.with_field("typed_value", Arc::new(typed_value_array))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check the variant shredding spec for arrays -- the typed_value for a shredded variant array is a non-nullable group called element, with child fields typed_value and value for shredded and unshredded list elements, respectively.

And then we'll need to build an appropriate GenericListArray out of this string array you built, which gives the offsets for each sub-list.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this too, I was under the wrong impression that the metadata encoding stores the offsets for the actual values. Reading your #8359 and rereading the Variant Encoding spec I see that the values offsets are within the value encoding itself.

So the outermost typed_value should be an GenericListArray of element - VariantObjects with {value and typed_value fields}?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, exactly! And element is non-nullable (**), while the two children are nullable.

(**) As always, in arrow, it can still have null entries, but only if its parent is already NULL for the same row (so nobody can ever observe a non-null element)

Copy link
Contributor

@scovich scovich left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand how these unit tests will translate to variant_get?

@sdf-jkl
Copy link
Contributor Author

sdf-jkl commented Sep 19, 2025

I'm not sure I understand how these unit tests will translate to variant_get?

Could you elaborate please?

I am currently trying to build just the Shredded List VariantArray test case, and while doing so learning how we could build them in shred_variant later. Once have a good way of building simple Shredded List VariantArray it will be easy to work on the rest of the unit tests for variant_get

@scovich
Copy link
Contributor

scovich commented Sep 19, 2025

I'm not sure I understand how these unit tests will translate to variant_get?

Could you elaborate please?

I am currently trying to build just the Shredded List VariantArray test case, and while doing so learning how we could build them in shred_variant later. Once have a good way of building simple Shredded List VariantArray it will be easy to work on the rest of the unit tests for variant_get

No worries -- the current iteration does look it produces a correct shredded variant containing a list, so I should probably just be patient and let you finish!

@sdf-jkl
Copy link
Contributor Author

sdf-jkl commented Sep 23, 2025

Hey @scovich I see that your current implementation of follow_shredded_path_element for VariantPathElement::Field when following the shredded path is successful, it returns a ShreddedPathStep::Success(field.shredding_state()) that holds a ShreddingState::Typed that holds a reference to the typed_value array. (That we later use for the next steps)

My question is: does ShreddedPathStep::Success() necessarily have to require the input ShreddingState to be a reference?

The reason I am asking is that since we use the output of follow_shredded_path_element to get the values from the shredded VariantArray, shouldn't we be free to drop the outer array once we extract the relevant typed_value?

The only way to work with list arrays I came up with so far, is to build new arrays with arrow_select::take, combining the path index and GenericListArray offsets.
But by using this method we create new arrays within the scope of the function and can't use a reference to the array in the ShreddedPathStep::Success.
(I just pushed a commit with a non-working implementation of the idea)

Should we instead look for another way to represent a resulting array consisting of slices instead?

I just saw the #8392

Comment on lines 135 to 152
// Build the list of indices to take
let mut take_indices = Vec::with_capacity(list_len);
for i in 0..list_len {
let start = offsets[i] as usize;
let end = offsets[i + 1] as usize;
let len = end - start;

if *index < len {
take_indices.push(Some((start + index) as u32));
} else {
take_indices.push(None);
}
}

let index_array = UInt32Array::from(take_indices);

// Use Arrow compute kernel to gather elements
let taken = take(field_array, &index_array, None)?;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can see the basic idea here

@sdf-jkl
Copy link
Contributor Author

sdf-jkl commented Sep 25, 2025

Hey @scovich I made it work for a one of the simple tests and it doesn't go through with the second one because Variant to Arrow does not support utf8 yet.

Do we have an issue tracking variant_to_arrow types support? If not, I can make one.

@scovich
Copy link
Contributor

scovich commented Sep 26, 2025

I made it work for a one of the simple tests and it doesn't go through with the second one because Variant to Arrow does not support utf8 yet.

Do we have an issue tracking variant_to_arrow types support? If not, I can make one.

I'm not sure we have a tracking issue for utf8 support in variant_to_arrow, but I've also noticed that it's an annoying gap for unit testing (we all seem to reach for string values...)

@github-actions github-actions bot added the arrow Changes to the arrow crate label Oct 22, 2025
Copy link
Contributor Author

@sdf-jkl sdf-jkl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Building on top of the utf8 variant_to_arrow support PR.
Changes in generic_bytes_builder.rs, generic_bytes_view_builder.rs and variant_to_arrow.rs are irrelevant.
Some changes in variant_get.rs and variant_array.rs are also from the utf8 pr, so they can be safely skipped.
Main changes are:

  • Adding ShreddingStateCow enum
  • Adding VariantPathElement::Index support for unnested List VariantArray

Comment on lines +106 to 164
let Some(list_array) = typed_value.as_any().downcast_ref::<GenericListArray<i32>>()
else {
// Downcast failure - if strict cast options are enabled, this should be an error
if !cast_options.safe {
return Err(ArrowError::CastError(format!(
"Cannot access index '{}' on non-list type: {}",
index,
typed_value.data_type()
)));
}
// With safe cast options, return NULL (missing_path_step)
return Ok(missing_path_step());
};

let offsets = list_array.offsets();
let values = list_array.values(); // This is a StructArray

let Some(struct_array) = values.as_any().downcast_ref::<StructArray>() else {
return Ok(missing_path_step());
};

let Some(typed_array) = struct_array.column_by_name("typed_value") else {
return Ok(missing_path_step());
};

// Build the list of indices to take
let mut take_indices = Vec::with_capacity(list_array.len());
for i in 0..list_array.len() {
let start = offsets[i] as usize;
let end = offsets[i + 1] as usize;
let len = end - start;

if *index < len {
take_indices.push(Some((start + index) as u32));
} else {
take_indices.push(None);
}
}

let index_array = UInt32Array::from(take_indices);

// Use Arrow compute kernel to gather elements
let taken = take(typed_array, &index_array, None)?;

let metadata_array = BinaryViewArray::from_iter_values(std::iter::repeat_n(
EMPTY_VARIANT_METADATA_BYTES,
taken.len(),
));

let struct_array = &StructArrayBuilder::new()
.with_field("metadata", Arc::new(metadata_array), false)
.with_field("typed_value", taken, true)
.build();

let state = ShreddingState::try_from(struct_array)?;
Ok(ShreddedPathStep::Success(state.into()))
}
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we use variant_get on Struct Variant Array's it's relatively easy to extract the typed_value. For example, if we extract a.b because on the inside it's just:

VariantArray{
    StructArray{
        "typed_value": 
            StructArray{
                "typed_value": PrimiteArray,  <- We can directly borrow the value into
                                                ShreddingState::Success() because the needed values in the array are contiguous 
                "value": VariantArray

But if we try to extract "typed_value" from a List VariantArray it gets more complicated. For example, extracting 0.0:

VariantArray{
    StructArray{
        "typed_value": 
            ListArray{
                Offsets
                StructArray{
                    "typed_value": PrimiteArray,  <- but the values are now not contiguous, and the
                                                   output array can only be extracted using offsets, no borrow available
                    "value": VariantArray

Because of this issue the output of follow_shredded_path_element -> ShreddedPathStep::Success can end up receiving BorrowedShreddingState or owned ShreddingState.

To make this work I added a ShreddingStateCow enum and made it the ShreddedPathStep::Success input.

Comment on lines +873 to +905
pub enum ShreddingStateCow<'a> {
Owned(ShreddingState),
Borrowed(BorrowedShreddingState<'a>),
}

impl<'a> From<ShreddingState> for ShreddingStateCow<'a> {
fn from(s: ShreddingState) -> Self {
Self::Owned(s)
}
}
impl<'a> From<BorrowedShreddingState<'a>> for ShreddingStateCow<'a> {
fn from(s: BorrowedShreddingState<'a>) -> Self {
Self::Borrowed(s)
}
}

impl<'a> ShreddingStateCow<'a> {
/// Always gives the caller a borrowed view, even if we own internally.
pub fn as_view(&self) -> BorrowedShreddingState<'_> {
match self {
ShreddingStateCow::Borrowed(b) => b.clone(),
ShreddingStateCow::Owned(o) => o.borrow(),
}
}

/// Materialize ownership when the caller needs to keep it.
pub fn into_owned(self) -> ShreddingState {
match self {
ShreddingStateCow::Borrowed(b) => b.into(),
ShreddingStateCow::Owned(o) => o,
}
}
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is the new ShreddingStateCow enum implementation

);
}
shredding_state = state;
shredding_state = ShreddingStateCow::Owned(state.into_owned());
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here I could not come up with a way to make the shredding_state for the next path_element be ither borrowed or owned depending on the follow_shredded_path_element output.

Made it into_owned() just to pass the borrow checker.

@sdf-jkl
Copy link
Contributor Author

sdf-jkl commented Oct 24, 2025

Hey @scovich, I'm ready for another go when you are available, thanks.

@github-actions github-actions bot removed the arrow Changes to the arrow crate label Nov 11, 2025
@sdf-jkl sdf-jkl requested a review from scovich November 11, 2025 03:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

parquet-variant parquet-variant* crates

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants