zeroshade commented on issue #811:
URL: https://github.com/apache/arrow-adbc/issues/811#issuecomment-2125621890

   > One could also just state that if the consumer returns something non-zero 
that no other callbacks will be called (I don't have strong feelings about any 
of this). 
   
   This was my original intention. Returning non-zero indicates that no other 
callbacks should be called. Only `Release`, I don't think we need to have the 
producer turn around and call the `on_error` with the code you returned. I do 
agree that using errno or AdbcStatusCode minimizes the number of types of 
things. Though we obviously can't use AdbcStatusCode if we're going to upstream 
this to the Arrow C Data Interface.
   
   > (I mean purpose vs just a plain bool, or gRPC's approach where you 
explicitly call cancel)
   
   Personally, I like putting more of the burden on the producer than the 
consumer. I'd prefer that the producer react to a non-zero return value by 
cancelling and then calling release than requiring the consumer to explicitly 
call cancel. That's just my personal opinion though, @CurtHagenlocher might 
have a better opinion on this given that he's likely to be an actual user of 
this API.
   
   > I believe that the schema->metadata encoding schema is capable of encoding 
the same blob key/value pairing as the ADBC errors. It would be a bit of a pain 
to pack/unpack it, of course, but any Arrow implementation supporting the C 
data interface probably can already do it.
   
   That's a good point. That could work pretty well then.
   
   > This admittedly gets quite awkward when trying to bind an array stream as 
a parameter, so ... probably not.
   
   Are we intending that the binding should be asynchronous too? I was thinking 
that the binding API would still be synchronous and binding a normal 
`ArrowArrayStream` since it would still be the driver itself calling the 
callbacks.
   
   It seems like we're approaching a small consensus on this, so if everyone is 
okay with it, i'll take the suggestions we've all discussed so far and try to 
come up with a potential proposal to upstream to the Arrow repo. Anyone object 
/ think there's more we need to discuss before I try?


-- 
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]

Reply via email to