paleolimbot opened a new pull request, #16: URL: https://github.com/apache/arrow-nanoarrow/pull/16
Fixes #8. After #14, users can already append to `struct ArrowBuffer`s, possibly element-wise, and use those buffers to make a valid `struct ArrowArray` (given some knowledge of the spec). Anybody who is *really* worried about speed should be doing this; however, in the context of appending element-wise it means that you have a lot of buffers to keep track of it's probably hard to make sure none of them leak (particularly without C++). This PR supports a workflow whereby one does `ArrowArrayInit()` (plus `ArrowArrayAllocateChildren()` + `ArrowArrayInit()` for nested types) first, then use `ArrowArrayReserveBuffer()`/`ArrowArrayAppendBufferUnsafe()` to create the buffers, or if nulls are a thing in the land where the elements originate, also the `ArrowArray*Bitmap()` equivalents. This uses the `struct ArrowArray` + the private data to make sure that child arrays/buffers are cleaned up. There should be helpers to append strings to (large) string/binary arrays that reserve/keep track of the offset buffer...that's common and verbose without help. Possibly the unsafe reservers/appenders should be typed (i.e, `ArrowArrayAppendBufferInt32Unsafe()`) so that nobody has to remember (or forget) to `* sizeof(int32_t)`. It would also possible to wire up `ArrowArrayReserve()` so that nobody has to worry about `sizeof()` at the reserve stage. For some nested types it might be possible to propagate that into child arrays, although perhaps that is too magical. -- 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. To unsubscribe, e-mail: issues-unsubscr...@arrow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
