feat: String/Binary View Support #596

WillAyd · 2024-08-23T19:35:24Z

closes #583

src/nanoarrow/common/inline_array.h

WillAyd · 2024-08-23T21:33:34Z

Hmm looks like the Python process whereby we generate the pxd file does not play nice with the union containing nested struct declarations

paleolimbot · 2024-08-25T00:36:09Z

I'm on vacation at the moment but I believe you just have to give the anonymous structures names (i.e. declare them as top level types). This is how you would have to do it in cython anyway i believe!

WillAyd · 2024-08-25T00:46:45Z

Sounds good. Enjoy the time away!

src/nanoarrow/common/inline_array.h

WillAyd · 2024-09-05T03:29:18Z

@paleolimbot started to look at this in more earnest to get a full round trip, instead of just a read. The current read implemenation also only assumes one variadic buffer.

I see the Arrow specification says that binary view types have an extra member which is a buffer containing the lengths of the variadic buffers:

https://arrow.apache.org/docs/format/CDataInterface.html#binary-view-arrays

Do you think its worth adding that to the ArrowArray struct, or should we create a new struct, potentially with a layout like:

struct ArrowBinaryViewArray {
  struct ArrowArray array_data;
  // Variadic buffer lengths for Binary View arrays
  int64_t* variadic_buffer_lengths;
};

So that it can be "safely" cast to/from ArrowArray pointers?

WillAyd · 2024-09-05T15:46:43Z

With that approach the one thing I still wonder is where we should store the length of variadic_buffer_lengths. I didn't see anything for that in the specification, so maybe using a NULL sentinel to denote the end of the array is the requirement?

paleolimbot · 2024-09-05T17:00:04Z

started to look at this in more earnest to get a full round trip, instead of just a read

Awesome!

Do you think its worth adding that to the ArrowArray struct, or should we create a new struct, potentially with a layout like:

I think the ArrowArrayView is the right place for this! From Joris' PR:

arrow-nanoarrow/src/nanoarrow/nanoarrow_types.h

Lines 794 to 796 in b3a9894

    
           int64_t n_varidic_buffers; 
        
           int64_t* variadic_buffer_sizes; 
        
           const void** variadic_buffers;

I see the Arrow specification says that binary view types have an extra member

I think this refers to an extra buffer (not an extra struct member):

https://github.com/apache/arrow-nanoarrow/pull/367/files#r1459338465

WillAyd · 2024-09-05T18:13:14Z

Ah OK interesting. Do you know if this is confirmed to be working upstream in Arrow? The reason I ask is that when running the test suite for what's already in this PR, when I hit the C++ Export method:

https://github.com/apache/arrow/blob/c2123b8b90ab952f854912459bb33ebaf0d99611/cpp/src/arrow/c/bridge.cc#L661

The n_buffers being assigned is just 3. I was (likely mistakenly) expecting that to be 4 to account for the validity buffer, inline/prefix buffer, variadic buffer(s), and a buffer that holds the sizes to all variadic buffers

The Arrow docs also read a little vague to me:

int64_t ArrowArray.n_buffers

Mandatory. The number of physical buffers backing this array. The number of buffers is a function of the data type, as described in the Columnar format specification, except for the the binary or utf-8 view type, which has one additional buffer compared to the Columnar format specification (see Binary view arrays).

Buffers of children arrays are not included.

I'm not sure if that is saying that the n_buffers argument should be 4 for the view types, or that it should be 3 and the consumer is expected to know that when working with view types, you actually have n_buffers + 1 buffers attached to the ArrowArray

WillAyd · 2024-09-05T18:22:37Z

Bah ignore what I just said - bad debugging. Digging deeper!

src/nanoarrow/common/array.c

src/nanoarrow/common/inline_array.h

src/nanoarrow/common/inline_types.h

codecov-commenter · 2024-09-19T00:13:52Z

Codecov Report

Attention: Patch coverage is 88.04348% with 11 lines in your changes missing coverage. Please review.

Project coverage is 86.06%. Comparing base (2c42268) to head (8c1e825).
Report is 22 commits behind head on main.

Files with missing lines	Patch %	Lines
src/nanoarrow/testing/testing.cc	14.28%	6 Missing ⚠️
src/nanoarrow/common/inline_types.h	0.00%	4 Missing ⚠️
src/nanoarrow/common/inline_array.h	98.64%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #596      +/-   ##
==========================================
+ Coverage   85.02%   86.06%   +1.04%     
==========================================
  Files          92       94       +2     
  Lines       11750    13697    +1947     
==========================================
+ Hits         9990    11788    +1798     
- Misses       1760     1909     +149

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

src/nanoarrow/common/array_test.cc

paleolimbot

A few more notes! I am gearing up for a release and it would be very cool to include this if we can...what do you see as blockers for getting this PR across the finish line and can I help with any of them?

paleolimbot · 2024-09-19T01:55:55Z

python/tests/test_schema.py

+    # TODO: run_end_encoded
+    assert na.binary_view().type == na.Type.BINARY_VIEW


Suggested change

# TODO: run_end_encoded

assert na.binary_view().type == na.Type.BINARY_VIEW

assert na.binary_view().type == na.Type.BINARY_VIEW

(we have an issue for this one, feel free to punt! #618)

Having a hard time deciphering the code suggestion - do you just want me to remove these?

I think it's just that you can remove the TODO

src/nanoarrow/common/array.c

WillAyd · 2024-09-19T02:39:14Z

A few more notes! I am gearing up for a release and it would be very cool to include this if we can...what do you see as blockers for getting this PR across the finish line and can I help with any of them?

Great! I should have time to see this through.

There are no major blockers from my end. Let me know any feedback you have and I will take a look

paleolimbot · 2024-09-19T03:15:47Z

Let me know any feedback you have and I will take a look

Great! I'll give this a thorough checkout + run through + review tomorrow 🙂

paleolimbot

I think a few changes are required to get this PR merged! This also needs a look from @bkietz to ensure that the string view details are correct!

src/nanoarrow/common/array.c

paleolimbot · 2024-09-20T14:44:23Z

src/nanoarrow/common/array_test.cc

+TEST(ArrayTest, ArrayTestAppendToBinaryViewArray) {
+  struct ArrowArray array;


Unless I'm missing something, these two tests can share a common void TestAppendToDataViewArray() to avoid duplicating this entire test? (I know we haven't done a great job of this in the test suite so far 😳)

Are you thinking that function should be added in the test suite or nanoarrow itself?

Just as a test pattern (like you added below for consolidating the builder tests):

void TestAppendToDataViewArray(enum ArrowType view_type) { // ... } TEST(ArrayTest, ArrayTestAppendToBinaryViewArray) { ASSERT_NO_FATAL_FAILURE(TestAppendToDataViewArray(NANOARROW_TYPE_BINARY_VIEW)); } TEST(ArrayTest, ArrayTestAppendToStringViewArray) { ASSERT_NO_FATAL_FAILURE(TestAppendToDataViewArray(NANOARROW_TYPE_STRING_VIEW)); }

Does it matter that the string test uses ArrowArrayAppendString whereas the binary one uses ArrowArrayAppendBytes for the append func? Should I just use ArrowArrayAppendBytes in the shared test implementation? Or parametrize it to accept a std::function?

Sorry for missing this comment! Probably we should test both functions to make sure they both work (I believe an if statement would work to get that coverage but we've also used std::function (for example, in the integration test json tests) and I think either works!

src/nanoarrow/common/inline_types.h

src/nanoarrow/testing/testing.cc

src/nanoarrow/common/schema.c

src/nanoarrow/common/utils.c

src/nanoarrow/common/inline_array.h

paleolimbot · 2024-09-20T15:26:36Z

src/nanoarrow/common/inline_array.h

+    } else {
+      int32_t n_vbufs = private_data->n_variadic_buffers;
+      if (n_vbufs == 0 ||
+          private_data->variadic_buffers[n_vbufs - 1].size_bytes + value.size_bytes >
+              NANOARROW_BINARY_VIEW_BLOCK_SIZE) {


I think the management of the array of buffers should be abstracted at least one level away to make it easier to spot potential problems and that here it would be more readable:

int64_t buffer_index; NANOARROW_RETURN_NOT_OK(ArrowArrayAddVariadicBuffers(array, 1, &buffer_index));

(Exposing the ability to reserve variadic buffers also unlocks the ability to build by buffer and is probably a good idea anyway).

Is the buffer_index in this case supposed to point to the index of the first buffer that has been added? If so, any preference for the name of that parameter?

Mostly just to tell you which one just got added (so that you can put a reference to it in the item you're about to append to the data buffer). Perhaps there's a better parameter name (or a way to retrieve the number of currently used variadic buffers using a function?)

Yea...struggling with what to name this, especially if we allow this function to add multiple buffers at once. Maybe the second function to get the number of buffers allocated is a better pattern?

So

int64_t nbuf_capacity = ArrowArrayVariadicBufferSize(struct ArrowArray *array); int64_t additional_buffers = 3; NANOARROW_RETURN_NOT_OK(ArrowArrayAddVariadicBuffers(array, additional_buffers)); // nbuf_capacity + additional_buffers == ArrowArrayVariadicBufferSize(struct ArrowArray *array);

versus

int64_t nbuf_capacity = private_data->n_variadic_buffers; int64_t next_buffer_avail; int64_t additional_buffers = 3; NANOARROW_RETURN_NOT_OK(ArrowArrayAddVariadicBuffers(array, additional_buffers, &next_buffer_avail)); // next_buffer_avail + additional_buffers == private_data->n_variadic_buffers;

Maybe the second function to get the number of buffers allocated is a better pattern?

Yes! Maybe ArrowArrayVariadicBufferCount() though? (Invoking Size suggests to me that there's only one of them and that the function will tell you how many bytes there are).

OK I think I've got this right. FWIW, maybe we would also add a ArrowArrayGetBuffer(struct ArrowArray* array, int32_t i) function to abstract many of the calls that have to reach into private_data as well?

I think we have this one!

arrow-nanoarrow/src/nanoarrow/common/inline_array.h

Lines 40 to 49 in 561de01

static inline struct ArrowBuffer* ArrowArrayBuffer(struct ArrowArray* array, int64_t i) {

struct ArrowArrayPrivateData* private_data =

(struct ArrowArrayPrivateData*)array->private_data;

switch (i) {

case 0:

return &private_data->bitmap.buffer;

default:

return private_data->buffers + i - 1;

}

}

We do use it a number of internals (but could possibly use it in others!)

bkietz · 2024-09-20T20:47:15Z

src/nanoarrow/common/inline_array.h

@@ -467,52 +468,136 @@ static inline ArrowErrorCode ArrowArrayAppendDouble(struct ArrowArray* array,
  return NANOARROW_OK;
 }

+#define NANOARROW_BINARY_VIEW_FIXED_BUFFERS 2
+#define NANOARROW_BINARY_VIEW_INLINE_SIZE 12
+#define NANOARROW_BINARY_VIEW_PREVIEW_SIZE 4


Nit: other implementations call this the prefix rather than the preview

Suggested change

#define NANOARROW_BINARY_VIEW_PREVIEW_SIZE 4

#define NANOARROW_BINARY_VIEW_PREFIX_SIZE 4

bkietz · 2024-09-20T20:51:36Z

src/nanoarrow/common/inline_array.h

+struct ArrowBinaryViewTypeInlinedData {
+  int32_t size;
+  uint8_t data[NANOARROW_BINARY_VIEW_INLINE_SIZE];
+};
+
+struct ArrowBinaryViewTypeRefData {
+  int32_t size;
+  uint8_t data[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];
+  int32_t buffer_index;
+  int32_t offset;
+};
+
+union ArrowBinaryViewType {


These types should probably avoid including Type in their name since they are values from an array of that type and don't encode type-level information. See also ArrowDecimal, ArrowStringView, ArrowInterval

Suggested change

struct ArrowBinaryViewTypeInlinedData {

int32_t size;

uint8_t data[NANOARROW_BINARY_VIEW_INLINE_SIZE];

};

struct ArrowBinaryViewTypeRefData {

int32_t size;

uint8_t data[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];

int32_t buffer_index;

int32_t offset;

};

union ArrowBinaryViewType {

struct ArrowBinaryViewInlined {

int32_t size;

uint8_t data[NANOARROW_BINARY_VIEW_INLINE_SIZE];

};

struct ArrowBinaryViewRef {

int32_t size;

uint8_t data[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];

int32_t buffer_index;

int32_t offset;

};

union ArrowBinaryView {

src/nanoarrow/common/inline_array.h

bkietz · 2024-09-20T21:15:32Z

src/nanoarrow/common/inline_array.h

+      if (n_vbufs == 0 ||
+          private_data->variadic_buffers[n_vbufs - 1].size_bytes + value.size_bytes >
+              NANOARROW_BINARY_VIEW_BLOCK_SIZE) {
+        NANOARROW_RETURN_NOT_OK(ArrowArrayAddVariadicBuffers(array, 1, &buf_index));


This doesn't handle the case where value.size_bytes > NANOARROW_BINARY_VIEW_BLOCK_SIZE, in that case you'll need an extra large variadic buffer to accommodate it

Ah OK interesting. So right now whenever a variadic buffer's capacity may be exceeded I am starting afresh in a new buffer - should I be packing the existing buffer as full as possible before-hand and potentially splitting the value array across two variadic buffers? Or is that only a consideration when value.size_bytes > NANOARROW_BINARY_VIEW_BLOCK_SIZE?

Ah, I wrote this before observing that you aren't presizing data buffers #596 (comment)

Since you aren't presizing this isn't a bug

bkietz · 2024-09-20T21:18:02Z

src/nanoarrow/common/inline_array.h

+
+struct ArrowBinaryViewTypeRefData {
+  int32_t size;
+  uint8_t data[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];


Suggested change

uint8_t data[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];

uint8_t prefix[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];

bkietz · 2024-09-20T21:18:34Z

src/nanoarrow/common/inline_array.h

+  }
+
+  for (int32_t i = 0; i < nbuffers; i++) {
+    ArrowBufferInit(&private_data->variadic_buffers[n_current_bufs + i]);


Suggested change

ArrowBufferInit(&private_data->variadic_buffers[n_current_bufs + i]);

ArrowBufferInit(&private_data->variadic_buffers[n_current_bufs + i]);

private_data->variadic_buffer_sizes[i] = 0;

bkietz · 2024-09-20T21:25:04Z

src/nanoarrow/common/inline_array.h

      NANOARROW_RETURN_NOT_OK(
-          ArrowBufferAppend(data_buffer, value.data.data, value.size_bytes));
-      break;
+          ArrowBufferAppend(variadic_buf, value.data.as_char, value.size_bytes));


This is fine for now, but the more usual pattern for building view arrays is to preallocate the data buffers (which reduces the frequency of reallocation)

Assuming we want to leave that to a follow up PR at this point, but is the idea that we would just pre-allocate the entire NANOARROW_BINARY_VIEW_BLOCK_SIZE bytes? Or is there a more refined algorithm?

I may be misunderstanding this, but would:

if (value.size_bytes < NANOARROW_BINARY_VIEW_BLOCK_SIZE) { NANOARROW_RETURN_NOT_OK(ArrowBufferReserve(variadic_buf, NANOARROW_BINARY_VIEW_BLOCK_SIZE)); }

...just after adding a new variadic buffer solve this? (Feel free to ignore if this is off base...I agree that there's no bug here!)

I think if we wanted to reserve the size of the buffer we should do it after adding it with the call to ArrowArrayAddVariadicBuffers

The blocking logic is rather specific to our appending, and we should make sure that others can implement their own logic if they want, which might have nothing to do with our block size. (Also, value.size_bytes is greater than the block size, that would result the initial reserve being immediately discarded).

bkietz · 2024-09-20T21:39:56Z

src/nanoarrow/common/inline_array.h

+      const union ArrowBufferViewData value_view = array_view->buffer_views[1].data;
+      union ArrowBinaryViewType bvt;
+      const size_t idx = sizeof(union ArrowBinaryViewType) * i;
+      memcpy(&bvt, value_view.as_uint8 + idx, sizeof(union ArrowBinaryViewType));
+      const int32_t inline_size = bvt.inlined.size;
+      view.size_bytes = inline_size;
+      if (inline_size <= NANOARROW_BINARY_VIEW_INLINE_SIZE) {
+        view.data.as_uint8 = value_view.as_uint8 + idx +
+                             sizeof(((union ArrowBinaryViewType*)0)->inlined.size);
+      } else {
+        const int32_t buf_index = bvt.ref.buffer_index;
+        const int32_t nfixed_buf = NANOARROW_BINARY_VIEW_FIXED_BUFFERS;
+        const struct ArrowBufferView variadic_vw =
+            ArrowArrayViewBufferView(array_view, buf_index + nfixed_buf);
+        view.data.as_uint8 = variadic_vw.data.as_uint8 + bvt.ref.offset;
+      }


I think it'd probably be best to add const struct ArrowBinaryView* as_binary_view; to union ArrowBufferViewData, and extract a function

static struct ArrowBufferView ArrowArrayViewGetBytesFromViewArrayUnsafe( const struct ArrowArrayView* array_view, int64_t i) { const struct ArrowBinaryView* bv = &array_view->buffer_views[1].data.as_binary_view[i]; struct ArrowBufferView out{.size_bytes = bv->inlined.size}; if (bv->inlined.size <= NANOARROW_BINARY_VIEW_INLINE_SIZE) { out.data.as_uint8 = bv->inlined.data; return out; } const int32_t buf_index = bv->ref.buf_index + NANOARROW_BINARY_VIEW_FIXED_BUFFERS; out.data.data = array_view->array->buffers[buf_index]; out.data.as_uint8 += bv->ref.offset; return out; }

(replacing ArrowArrayViewBufferView).

Then we can rewrite this as:

Suggested change

const union ArrowBufferViewData value_view = array_view->buffer_views[1].data;

union ArrowBinaryViewType bvt;

const size_t idx = sizeof(union ArrowBinaryViewType) * i;

memcpy(&bvt, value_view.as_uint8 + idx, sizeof(union ArrowBinaryViewType));

const int32_t inline_size = bvt.inlined.size;

view.size_bytes = inline_size;

if (inline_size <= NANOARROW_BINARY_VIEW_INLINE_SIZE) {

view.data.as_uint8 = value_view.as_uint8 + idx +

sizeof(((union ArrowBinaryViewType*)0)->inlined.size);

} else {

const int32_t buf_index = bvt.ref.buffer_index;

const int32_t nfixed_buf = NANOARROW_BINARY_VIEW_FIXED_BUFFERS;

const struct ArrowBufferView variadic_vw =

ArrowArrayViewBufferView(array_view, buf_index + nfixed_buf);

view.data.as_uint8 = variadic_vw.data.as_uint8 + bvt.ref.offset;

}

view = ArrowArrayViewGetBytesFromViewArrayUnsafe(string_array, i);

and ArrowArrayViewGetStringUnsafe's case as

case NANOARROW_TYPE_STRING_VIEW: case NANOARROW_TYPE_BINARY_VIEW: { struct ArrowBufferView buf_view = ArrowArrayViewGetBytesFromViewArrayUnsafe(string_array, i); view.data = buf_view.data.as_char; view.size_bytes = buf_view.size_bytes; break; }

Awesome idea - thanks!

bkietz

Just a few more nits, looking good

src/nanoarrow/common/array.c

src/nanoarrow/common/array_test.cc

paleolimbot

This is huge! Thank you!

WillAyd commented Aug 23, 2024

View reviewed changes

src/nanoarrow/common/inline_array.h Outdated Show resolved Hide resolved

WillAyd force-pushed the string-view branch from 77a9b20 to a66af4f Compare August 23, 2024 21:16

WillAyd force-pushed the string-view branch from 653354c to 3f9e416 Compare August 24, 2024 14:51

WillAyd force-pushed the string-view branch from b0707d6 to 013aff1 Compare August 29, 2024 01:53

WillAyd commented Sep 4, 2024

View reviewed changes

src/nanoarrow/common/inline_array.h Outdated Show resolved Hide resolved

WillAyd force-pushed the string-view branch 4 times, most recently from 0b11479 to 00fbf17 Compare September 4, 2024 23:28

WillAyd marked this pull request as ready for review September 4, 2024 23:36

WillAyd marked this pull request as draft September 5, 2024 01:50

WillAyd added 8 commits September 5, 2024 13:12

feat: Implement read support for String/Binary View types

9c650c8

Python support

61f9272

Define struct members outside of the union

7f3e43b

no macros

e96c7ab

trade some hacks

70a566f

Python fixes

ac375e9

Add missing case

6992461

checkpoint

bdb25ab

Working read test with new ArrayView struct members

9d7e806

WillAyd force-pushed the string-view branch from 79dd9f1 to 9d7e806 Compare September 5, 2024 20:35

WillAyd commented Sep 5, 2024

View reviewed changes

src/nanoarrow/common/array.c Outdated Show resolved Hide resolved

src/nanoarrow/common/array.c Outdated Show resolved Hide resolved

src/nanoarrow/common/inline_array.h Show resolved Hide resolved

src/nanoarrow/common/inline_types.h Show resolved Hide resolved

WillAyd added 2 commits September 18, 2024 16:24

Add tests for block size logic

2cdcfc6

Add RUN_END_ENCODED to Python enum

8c1e825

WillAyd commented Sep 19, 2024

View reviewed changes

src/nanoarrow/common/array_test.cc Outdated Show resolved Hide resolved

paleolimbot reviewed Sep 19, 2024

View reviewed changes

WillAyd added 2 commits September 18, 2024 22:22

No variadic_buffer_views member

40540a4

Use 64 bit variadic_buffer_sizes

561de01

WillAyd mentioned this pull request Sep 19, 2024

Add Iterator Overloads for String/Binary View #623

Closed

WillAyd marked this pull request as ready for review September 19, 2024 02:38

paleolimbot reviewed Sep 20, 2024

View reviewed changes

feedback

ea4208a

WillAyd force-pushed the string-view branch from c501d49 to ea4208a Compare September 20, 2024 17:58

bkietz requested changes Sep 20, 2024

View reviewed changes

WillAyd added 2 commits September 21, 2024 09:41

More Dewey feedback

9bbf43e

bkietz feedback

74418fd

WillAyd force-pushed the string-view branch from d41254b to 74418fd Compare September 21, 2024 14:32

Remove TODO

8283f01

bkietz requested changes Sep 23, 2024

View reviewed changes

src/nanoarrow/common/array.c Outdated Show resolved Hide resolved

src/nanoarrow/common/array_test.cc Outdated Show resolved Hide resolved

WillAyd added 2 commits September 23, 2024 13:28

More feedback

1fd69e9

Reduce test duplication

313481f

WillAyd force-pushed the string-view branch from a21f45a to 313481f Compare September 23, 2024 19:47

WillAyd changed the title ~~feat: Implement read support for String/Binary View types~~ feat: String/Binary View Support Sep 23, 2024

bkietz approved these changes Sep 23, 2024

View reviewed changes

paleolimbot approved these changes Sep 24, 2024

View reviewed changes

paleolimbot merged commit 6f8badb into apache:main Sep 24, 2024
42 checks passed

WillAyd deleted the string-view branch September 24, 2024 06:16

paleolimbot mentioned this pull request Sep 24, 2024

feat: Support for Binaryview and StringView types #367

Closed

GregoryKimball mentioned this pull request Oct 9, 2024

[FEA] Accelerate conversion from arrow::StringViewType to arrow::StringType in libcudf interop rapidsai/cudf#15298

Open

		# TODO: run_end_encoded
		assert na.binary_view().type == na.Type.BINARY_VIEW

		TEST(ArrayTest, ArrayTestAppendToBinaryViewArray) {
		struct ArrowArray array;

	static inline struct ArrowBuffer* ArrowArrayBuffer(struct ArrowArray* array, int64_t i) {
	struct ArrowArrayPrivateData* private_data =
	(struct ArrowArrayPrivateData*)array->private_data;
	switch (i) {
	case 0:
	return &private_data->bitmap.buffer;
	default:
	return private_data->buffers + i - 1;
	}
	}

	#define NANOARROW_BINARY_VIEW_PREVIEW_SIZE 4
	#define NANOARROW_BINARY_VIEW_PREFIX_SIZE 4

	uint8_t data[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];
	uint8_t prefix[NANOARROW_BINARY_VIEW_PREVIEW_SIZE];

	ArrowBufferInit(&private_data->variadic_buffers[n_current_bufs + i]);
	ArrowBufferInit(&private_data->variadic_buffers[n_current_bufs + i]);
	private_data->variadic_buffer_sizes[i] = 0;

feat: String/Binary View Support #596

feat: String/Binary View Support #596

Conversation

WillAyd commented Aug 23, 2024 • edited Loading

WillAyd commented Aug 23, 2024

paleolimbot commented Aug 25, 2024

WillAyd commented Aug 25, 2024

WillAyd commented Sep 5, 2024 • edited Loading

WillAyd commented Sep 5, 2024

paleolimbot commented Sep 5, 2024

WillAyd commented Sep 5, 2024 • edited Loading

WillAyd commented Sep 5, 2024

codecov-commenter commented Sep 19, 2024

Codecov Report

paleolimbot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WillAyd commented Sep 19, 2024

paleolimbot commented Sep 19, 2024

paleolimbot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bkietz left a comment

Choose a reason for hiding this comment

paleolimbot left a comment

Choose a reason for hiding this comment

WillAyd commented Aug 23, 2024 •

edited

Loading

WillAyd commented Sep 5, 2024 •

edited

Loading

WillAyd commented Sep 5, 2024 •

edited

Loading