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
Describe the bug
There used to be no standard way of creating native Arrow types, and the documentation is ambiguous as to physical memory layout. As such, I thought it would be a good idea to create standardized make_value() and to_parts() methods for each type. Due to reasons I no longer remember, I thought months, days, and nanos were stored in reverse order.
@alamb found my mistake in this PR. I have since tracked down the C implementation structs to confirm the implementation (and unit tests) are now correct, as well as adding ascii art documentation to help communicate the memory format to future contributors.
To Reproduce
Invoke IntervalMonthDayNanoType::make_value() to create a duration, then attempt to pass it to C/Python/Java for decoding.
Expected behavior
The generated value conforms to specifications.
The text was updated successfully, but these errors were encountered:
Describe the bug
There used to be no standard way of creating native Arrow types, and the documentation is ambiguous as to physical memory layout. As such, I thought it would be a good idea to create standardized
make_value()
andto_parts()
methods for each type. Due to reasons I no longer remember, I thought months, days, and nanos were stored in reverse order.@alamb found my mistake in this PR. I have since tracked down the C implementation structs to confirm the implementation (and unit tests) are now correct, as well as adding ascii art documentation to help communicate the memory format to future contributors.
To Reproduce
Invoke
IntervalMonthDayNanoType::make_value()
to create a duration, then attempt to pass it to C/Python/Java for decoding.Expected behavior
The generated value conforms to specifications.
The text was updated successfully, but these errors were encountered: