It looks like this would be trickier than I first expected: ffi::ArrowArray is
created from an ArrayData, which itself doesn't appear to contain any name. I
don't suppose we'd want to add a name property to it just for this.
Any guidance on a mechanism to get the name through to the FFI_ArrowSchema
without an unreasonably large refactor would be appreciated!
–Marc
On 2021/02/20 15:19:00, Marc Prud'hommeaux <mprud...@apache.org> wrote:
>
> Great! I will start experimenting and see how far I get.
>
> While we're at it, should we consider putting something in the metadata
> field? That would be more involved due to the bespoke format of the property,
> but it might be a good time to consider any additional information that could
> be useful to include in there.
>
> –Marc
>
> On 2021/02/20 04:19:14, Jorge Cardoso Leitão <jorgecarlei...@gmail.com>
> wrote:
> > No reason in particular: please go ahead!
> >
> > tips: anything that is to be deallocated when exporting must go to "private
> > data" and deallocated by the extern "C" release bit, as we do in the
> > DataType string. Think of that function as the "Drop" equivalent for ffi.
> >
> > Best,
> > Jorge
> >
> >
> > On Sat, Feb 20, 2021 at 4:24 AM Marc Prud'hommeaux <mprud...@apache.org>
> > wrote:
> >
> > > When I export to the C data interface structs with array.to_raw(), I'm
> > > seeing that FFI_ArrowSchema.name is always null. And looking at
> > > ArrowArray::try_new, it appears that FFI_ArrowSchema is only ever created
> > > with a format argument; name and metadata are never set to anything.
> > >
> > > Is there any specific reason why FFI_ArrowSchema.name is left unset? If
> > > not, I'd like to take a shot at implementing it. Any implementation tips
> > > would be welcome.
> > >
> > > –Marc
> > >
> > >
> >
>
