zeroshade opened a new issue, #61:
URL: https://github.com/apache/arrow-adbc/issues/61

   Rather than the separate `Execute` / `GetStream` functions, it might be 
better to follow something similar to FlightSQL's interface or Go's 
`database/sql` API.
   
   Have two functions:
   
   * Execute a query without expecting a result set: `Execute(struct 
AdbcConnection*, const char*, struct AdbcResult*, struct AdbcError*)` where 
`AdbcResult` would contain an optional LastInsertedID and Number of Rows 
affected
   * Execute a query to retrieve a result set: `Query(struct AdbcConnection*, 
const char*, struct ArrowArrayStream*, struct AdbcError*)` where the 
`ArrowArrayStream` is populated with the result set.
   
   Corresponding methods would exist for a Statement just without the need for 
taking the `const char*` as it would already be prepared in the statement.
   
   Some benefits of this idea:
   * With the interface enforcing the idea of the query -> retrieving the 
results being a single API call it makes concurrency easier to handle (any 
complexity would be handled by the driver implementation) by consumers of the 
interface.
   * Drivers can be aware of whether or not a user is expecting a result set 
and can operate accordingly. They don't have to interrogate the backend to know 
whether or not a result set is available or if the query was an update/insert 
vs a select.


-- 
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: issues-unsubscr...@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to