You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Related to #1404, generate_unions_case integration test case.
We keep a vector of Field and a UnionMode in Union datatype now. According to Arrow spec, it only specifies the type ids are 8bit signed integers. So the type ids can be arbitrary integers only if they can be matched with children arrays' type ids. This is how UnionType in C++ implementation works.
Currently this crate assumes that the type ids of Union are monotonically increasing from 0 (i.e., 0, 1, 2...). When integrating with other implementations like C++, this assumption will cause error in receiving/sending UnionArray.
Describe the solution you'd like
We should keep type ids in Union datatype like C++ UnionType. The type ids are given when creating Union datatype. UnionArray related code should not assume the type ids are monotonically increasing from 0.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
Related to #1404,
generate_unions_case
integration test case.We keep a vector of
Field
and aUnionMode
inUnion
datatype now. According to Arrow spec, it only specifies the type ids are 8bit signed integers. So the type ids can be arbitrary integers only if they can be matched with children arrays' type ids. This is how UnionType in C++ implementation works.Currently this crate assumes that the type ids of
Union
are monotonically increasing from 0 (i.e., 0, 1, 2...). When integrating with other implementations like C++, this assumption will cause error in receiving/sending UnionArray.Describe the solution you'd like
We should keep type ids in
Union
datatype like C++UnionType
. The type ids are given when creatingUnion
datatype.UnionArray
related code should not assume the type ids are monotonically increasing from 0.Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: