paleolimbot opened a new issue, #70: URL: https://github.com/apache/arrow-nanoarrow/issues/70
...based on writing some nanoarrow code in the R package, https://github.com/geoarrow/geoarrow-cpp/ , and https://github.com/paleolimbot/minigpkg/ A few that may be nice are: - `ArrowBufferAppendStringView()` (i.e., `ArrowBufferAppendStringView(buffer, ArrowCharView("some string");`) - `ArrowBufferAppendBufferView()` (i.e., `ArrowBufferAppendBufferView(buffer, some_array_view->buffer_views[1])`) - `ArrowArrayMove(struct ArrowArray* src, struct ArrowArray* dst)`, `ArrowSchemaMove(struct ArrowSchema* src, struct ArrowSchema* dst)`, and `ArrowArrayStreamMove(struct ArrowArrayStream* src, struct ArrowArrayStream* dst)` (more readable than `memcpy(dst, src, sizeof(struct ArrowSomething); src->release = NULL;`) Another thing that came up is a pattern for unsafe appends. The buffer appenders in the `ArrowBufferAppendInt32()` family all check and possibly reallocate; the array appenders in the `ArrowArrayAppendInt()` family do a `switch()` on type and range checks to help prevent implicit overflow. Adding more convenience around this like maybe `ArrowBufferAppendInt32Unsafe()` or `ArrowArrayInt32AppendInt32Unsafe()` is probably very verbose and isn't that hard to work around. I could be convinced either way on whether they should exist or not. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
