Thanks Andrew and Jorge for the help.
I think the use of the ScalarValue enum is precisely what I want. I was
worried that downcasting the column every time you need to get a value
would be slow but I can see that you are doing that with the ScalarValue
enum (
https://github.com/apache/arrow/blob/
In the application I'm working on I'm reading a parquet file and creating a
table to keep the records in memory.
This gist has the idea of it
https://gist.github.com/elferherrera/a2a796ae83a7203f58de704c178c44ef
I would like to keep it as pure Arrow because I have found that it is super
fast to c
I agree with Andrew (as usual) :)
Irrespectively, maybe it is easier if you could describe what you are
trying to accomplish, Fernando. There are possibly other ways of going
about this,
and maybe someone can help by knowing more context.
Best,
Jorge
On Thu, Jan 28, 2021 at 1:06 PM Andrew Lamb
I think this approach would work (and we have something similar in
DataFusion (ScalarValue)
https://github.com/apache/arrow/blob/4b7cdcb9220b6d94b251aef32c21ef9b4097ecfa/rust/datafusion/src/scalar.rs#L46
-- though it is an enum rather than a Trait, I think the idea is basically
the same)
I think t
Hi Jorge,
What about making the Array::value return a &dyn ValueTrait. This new
ValueTrait would have to be implemented for all the possible values that
can be returned from the arrays
Fernando
On Thu, 28 Jan 2021, 08:42 Jorge Cardoso Leitão,
wrote:
> Hi Fernando,
>
> I tried that some time ag
Hi Fernando,
I tried that some time ago, but I was unable to do so. The reason is that
Array is a trait that needs to support also being a trait object (i.e.
support `&dyn Array`).
Let's try here: what type should `Array::value` return? One option is to
make Array a generic. But if Array is a gen
I see what you mean. I was thinking that the function signature would have
to be something like this:
trait Array {
>fn value(&self) -> T
> }
Where T would have to implement another trait, call it ValueTrait, in order
to define how to extract the different values types, e.g. &str, u32, etc.
I think the idea is enticing, but it comes with some challenges:
1. Rust is strongly typed so when extracting values we would likely need a
`Scalar` type enum or multiple different `value_bool`, `value_u64` type
functions
2. Such access would likely be much slower (though possible more
convenient)
Hi,
I'm wondering if it has been considered to move the value function that is
implemented in all the arrays (StringArray, BooleanArray, ListArray, etc)
as part of the Array trait?
This would help when extracting values from generic arrays that implement
dyn Array without having to manually downc
