I've merged https://github.com/apache/arrow/pull/14079. (Note this doesn't add
any code artifacts to 10.0.0; it just describes the specification as part of
the format documentation.)
-David
On Mon, Oct 10, 2022, at 07:39, David Li wrote:
> My vote: +1
>
> The vote passes with 4 binding +1
My vote: +1
The vote passes with 4 binding +1 votes, 8 non-binding +1 votes, and no -1
votes. Thanks all!
I will update the RFC PR and merge it next, and will continue setting up the CI
and release process.
-David
On Wed, Oct 5, 2022, at 15:38, David Li wrote:
> Kirill (CC'd) mentioned the
+1 (non-binding), but still working on embedding it into the R adbc
package, and might come back with feedback: https://github.com/r-dbi/adbc
On 2022/09/21 15:40:11 David Li wrote:
> Hello,
>
> We have been discussing [1] standard interfaces for Arrow-based
database access and have been
Kirill (CC'd) mentioned the organization could be improved [1] - I've put up a
PR to move the definitions around to make it easier for implementors [2].
I'll leave this thread open for a little while longer for any interested
parties/see if anyone has PR comments before I'll merge the
+1
(I think this makes 4 binding +1s, if I count correctly)
On Wed, Oct 5, 2022 at 11:30 AM Antoine Pitrou wrote:
>
> +1 (binding), with the caveat that I looked mostly at the C API.
>
> Regards
>
> Antoine.
>
>
> Le 21/09/2022 à 17:40, David Li a écrit :
> > Hello,
> >
> > We have been
+1 (binding), with the caveat that I looked mostly at the C API.
Regards
Antoine.
Le 21/09/2022 à 17:40, David Li a écrit :
Hello,
We have been discussing [1] standard interfaces for Arrow-based database access and have
been working on implementations of the proposed interfaces [2], all
+ 1 (non-binding)
On Tue, Oct 4, 2022 at 11:05 PM David Li wrote:
> Just another reminder - this has been open for a while with only one
> binding vote. I know it's near 10.0.0 and I don't expect this to make the
> release, but I'd appreciate if we could get this wrapped up one way or
>
Just another reminder - this has been open for a while with only one binding
vote. I know it's near 10.0.0 and I don't expect this to make the release, but
I'd appreciate if we could get this wrapped up one way or another.
Thanks,
David
On Wed, Sep 28, 2022, at 21:55, Steven Deobald wrote:
>
+1 (non-binding)
On Tue, 27 Sept 2022 at 14:20, David Li wrote:
> Hi all,
>
> Just a reminder that this vote is still outstanding - if anyone (PMC or
> not) is interested in taking a look. Thanks!
>
> -David
>
> On Thu, Sep 22, 2022, at 05:40, Antoine Pitrou wrote:
> > Hello,
> >
> > I would
Hi all,
Just a reminder that this vote is still outstanding - if anyone (PMC or not) is
interested in taking a look. Thanks!
-David
On Thu, Sep 22, 2022, at 05:40, Antoine Pitrou wrote:
> Hello,
>
> I would urge people to review the proposed ADBC APIs, especially the Go
> and Java APIs which
+1
In
"[VOTE] Adopt ADBC database client connectivity specification" on Wed, 21 Sep
2022 11:40:11 -0400,
"David Li" wrote:
> Hello,
>
> We have been discussing [1] standard interfaces for Arrow-based database
> access and have been working on implementa
+1
(non-binding)
Gavin Ray 于2022年9月23日周五 03:40写道：
> Ah yeah that's true, good point
>
>
>
> On Thu, Sep 22, 2022 at 2:38 PM David Li wrote:
>
> > I suppose the separator would have to be known to the client somehow
> > (perhaps as metadata) - you'd have the same problem in the opposite
> >
Ah yeah that's true, good point
On Thu, Sep 22, 2022 at 2:38 PM David Li wrote:
> I suppose the separator would have to be known to the client somehow
> (perhaps as metadata) - you'd have the same problem in the opposite
> direction if the result were a list right? You wouldn't be able to
>
I suppose the separator would have to be known to the client somehow (perhaps
as metadata) - you'd have the same problem in the opposite direction if the
result were a list right? You wouldn't be able to concatenate the parts
together without knowing a safe separator to use.
On Thu, Sep 22,
Wait, what happens if a datasource's spec allows dots as valid identifiers?
On Thu, Sep 22, 2022 at 2:22 PM Gavin Ray wrote:
> Ah okay, yeah that's a reasonable angle too haha
>
>
> On Thu, Sep 22, 2022 at 1:59 PM David Li wrote:
>
>> Frankly it was from a "not drastically refactoring things"
Ah okay, yeah that's a reasonable angle too haha
On Thu, Sep 22, 2022 at 1:59 PM David Li wrote:
> Frankly it was from a "not drastically refactoring things" perspective :)
>
> At least for Arrow: list[utf8] is effectively a utf8 array with an extra
> array of offsets, so there's relatively
Frankly it was from a "not drastically refactoring things" perspective :)
At least for Arrow: list[utf8] is effectively a utf8 array with an extra array
of offsets, so there's relatively little overhead. (In particular, there's not
an extra allocation per array; there's just an overall
I suppose you're thinking from a memory/performance perspective right?
Allocating a dot character is a lot better than allocating multiple arrays
Yeah I don't see why not -- this could even be a library internal where the
fact that it's dotted is an implementation detail
Then in the Java
Ah, interesting…
A self-recursive schema wouldn't work in Arrow's schema system, so it'd have to
be the latter solution. Or, would it work to have a dotted name in the schema
name column? Would parsing that back out (for applications that want to work
with the full hierarchy) be too much
Antoine, I can't comment on the Go code (not qualified) but to me, the
"verification" test
examples look like a mixture between JDBC and Java FlightSQL driver usage,
and seem solid.
There was one reservation I had about the ability to handle datasource
namespacing that I brought up early on in
Hello,
I would urge people to review the proposed ADBC APIs, especially the Go
and Java APIs which probably benefitted from less feedback than the C one.
Regards
Antoine.
Le 21/09/2022 à 17:40, David Li a écrit :
Hello,
We have been discussing [1] standard interfaces for Arrow-based
+1 (non-binding)
On Wed, Sep 21, 2022 at 1:16 PM Matthew Topol
wrote:
> +1 (non-binding)!
>
> On Wed, Sep 21, 2022 at 1:34 PM Dewey Dunnington
> wrote:
>
> > +1! (non-binding)
> >
> > On Wed, Sep 21, 2022 at 12:47 PM Gavin Ray
> wrote:
> >
> > > +1 (non-binding/I'm not important)
> > >
> > >
+1 (non-binding)!
On Wed, Sep 21, 2022 at 1:34 PM Dewey Dunnington
wrote:
> +1! (non-binding)
>
> On Wed, Sep 21, 2022 at 12:47 PM Gavin Ray wrote:
>
> > +1 (non-binding/I'm not important)
> >
> > On Wed, Sep 21, 2022 at 11:40 AM David Li wrote:
> >
> > > Hello,
> > >
> > > We have been
+1! (non-binding)
On Wed, Sep 21, 2022 at 12:47 PM Gavin Ray wrote:
> +1 (non-binding/I'm not important)
>
> On Wed, Sep 21, 2022 at 11:40 AM David Li wrote:
>
> > Hello,
> >
> > We have been discussing [1] standard interfaces for Arrow-based database
> > access and have been working on
+1 (non-binding/I'm not important)
On Wed, Sep 21, 2022 at 11:40 AM David Li wrote:
> Hello,
>
> We have been discussing [1] standard interfaces for Arrow-based database
> access and have been working on implementations of the proposed interfaces
> [2], all under the name "ADBC". This proposal
Hello,
We have been discussing [1] standard interfaces for Arrow-based database access
and have been working on implementations of the proposed interfaces [2], all
under the name "ADBC". This proposal aims to provide a unified client
abstraction across Arrow-native database protocols (like
26 matches
Mail list logo
