alamb commented on a change in pull request #10073:
URL: https://github.com/apache/arrow/pull/10073#discussion_r615736126
##########
File path: rust/arrow/src/compute/kernels/concat.rs
##########
@@ -384,4 +384,51 @@ mod tests {
Ok(())
}
+
+ fn collect_string_dictionary(
+ dictionary: &DictionaryArray<Int32Type>,
+ ) -> Vec<Option<String>> {
+ let values = dictionary.values();
+ let values = values.as_any().downcast_ref::<StringArray>().unwrap();
+
+ (0..dictionary.len())
+ .map(move |i| match dictionary.keys().is_valid(i) {
+ true => {
+ let key = dictionary.keys().value(i);
+ Some(values.value(key as _).to_string())
+ }
+ false => None,
+ })
+ .collect()
+ }
+
+ #[test]
+ fn test_string_dictionary_array() -> Result<()> {
+ let input_1: DictionaryArray<Int32Type> =
+ vec!["hello", "A", "B", "hello", "hello", "C"]
+ .into_iter()
+ .collect();
+ let input_2: DictionaryArray<Int32Type> =
+ vec!["hello", "E", "E", "hello", "F", "E"]
+ .into_iter()
+ .collect();
+
+ let concat = concat(&[&input_1 as _, &input_2 as _]).unwrap();
+ let concat = concat
+ .as_any()
+ .downcast_ref::<DictionaryArray<Int32Type>>()
+ .unwrap();
+
Review comment:
> Edit: I've taken a guess at what you meant and hardcoded the expected
result instead of computing it
Yes, I meant a hard coded expected result.
The rationale being that then no change or bug in the arrow implementation
can cause the expected results to change. By comparing the output of `concat`
(which calls `concat_dictionary`) to `concat_dictionary` I was thinking that a
bug in `concat_dictionary` could be masked in some cases
--
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.
For queries about this service, please contact Infrastructure at:
[email protected]
