You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of small bugs in the Java Flight SQL example (e.g. binding parameters to the wrong index, not handling null parameter values, not properly reporting errors, things throwing SQLException that should use Arrow/general Java exceptions) that should be fixed.
Also, CommandPreparedStatementQuery is implemented wrong in both C++ and Java servers: only the last parameter value will be bound/executed when executing a prepared statement that returns a result set. But this contradicts the spec, which states "All of the bound parameter sets will be executed as a single atomic execution". The server(s) need to cache the uploaded Arrow data and execute using all input rows.
David Li / @lidavidm:
CC @jduo: is the behavior for CommandPreparedStatementQuery here expected? Right now, in DoPut, the Java/C++ servers bind each row successively, but don't actually execute anything. So when you go to actually execute the query later, you get only one result row (corresponding to the last parameter row).
James Duong / @jduo:
The intent for using DoPut to bind parameters was more geared around using parameters for write – it models the behavior of executing a write with an array of parameters an ODBC or PreparedStatement.executeBatch() in JDBC.
For the query case the spec is left open as this iteration of the spec did not include support for multiple result sets.
David Li / @lidavidm:
Thanks - I'll start a discussion and probably roll it up into the existing proposal, since this would be potentially useful to cover
There are a number of small bugs in the Java Flight SQL example (e.g. binding parameters to the wrong index, not handling null parameter values, not properly reporting errors, things throwing SQLException that should use Arrow/general Java exceptions) that should be fixed.
Also, CommandPreparedStatementQuery is implemented wrong in both C++ and Java servers: only the last parameter value will be bound/executed when executing a prepared statement that returns a result set. But this contradicts the spec, which states "All of the bound parameter sets will be executed as a single atomic execution". The server(s) need to cache the uploaded Arrow data and execute using all input rows.
Reporter: David Li / @lidavidm
Assignee: David Li / @lidavidm
Related issues:
PRs and other links:
Note: This issue was originally created as ARROW-17199. Please see the migration documentation for further details.
The text was updated successfully, but these errors were encountered: