jorisvandenbossche commented on code in PR #1346:
URL: https://github.com/apache/arrow-adbc/pull/1346#discussion_r1417576608
##########
python/adbc_driver_manager/adbc_driver_manager/_lib.pyx:
##########
@@ -316,23 +348,56 @@ cdef class ArrowSchemaHandle:
"""The address of the ArrowSchema."""
return <uintptr_t> &self.schema
+ def __arrow_c_schema__(self) -> object:
+ """Consume this object to get a PyCapsule."""
+ # Reference:
+ #
https://arrow.apache.org/docs/dev/format/CDataInterface/PyCapsuleInterface.html#create-a-pycapsule
+ cdef CArrowSchema* allocated = <CArrowSchema*>
malloc(sizeof(CArrowSchema))
+ allocated.release = NULL
+ capsule = PyCapsule_New(
+ <void*>allocated, "arrow_schema", &pycapsule_schema_deleter,
+ )
+ memcpy(allocated, &self.schema, sizeof(CArrowSchema))
+ self.schema.release = NULL
+ return capsule
Review Comment:
We are "moving" the schema here, while in nanoarrow I opted for a hard copy
for the schema (using nanoarrow's `ArrowSchemaDeepCopy`).
But I think the only advantage of a hard copy is that this means you can
consume it multiple times? (or in the case of nanoarrow-python, that the
nanoarrow Schema object is still valid and inspectable after it has been
converted to eg a pyarrow.Schema)
For ADBC, I think the use case will be much more "receive handle and convert
it directly once", given that the Handle object itself isn't useful at all (in
contrast to nanoarrow.Schema), so moving here is probably fine?
--
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]
