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
{{ message }}
Repository navigation
[JDBC] Batches of PreparedStatements only execute first statement #1412
Describe the bug, including details regarding any error messages, version, and platform.
Description
When executing a batch of INSERT using PreparedStatement.executeBatch()only the first statement is being executed in the database. The return value is an integer array with a single integer. This is not JDBC-compliant behavior, as it should either return an array of update counts containing one element for each command in the batch on successful execution of every command or throw an exception.
Steps to reproduce
1- Create a writable source in Dremio with INSERT privilege
2- Execute a batch of multiple INSERT commands on a PreparedStatement
Run main()method of the attached class to reproduce the bug. The code assumes that you have a writable source, with INSERT privilege, named nas, and that this source has a table named my_table which has a single VARCHAR(100) column.
I reviewed this issue along with the ongoing draft in PR #1411. Ensuring PreparedStatement.executeBatch() is fully JDBC-compliant by executing each parameter set and draining PutResult streams without allocator leaks is a valuable fix.
The expected approach entails:
Iterating through all queued parameter sets in ArrowFlightSqlPreparedStatement / batch executor.
Collecting individual update counts into int[] matching the batch size.
Guaranteeing that Flight SQL streams and allocated vectors are cleanly drained and closed in finally blocks.
Catching intermediate failures and throwing a BatchUpdateException containing partial update counts per JDBC spec.
@mykolapavlov-dremio, are you actively working on finalizing PR #1411, or would you welcome assistance / a rebased PR to help get this across the finish line with complete unit tests? Happy to collaborate!
Activity
kaifkhan93544 commentedon Nov 2, 2026
Hi @mykolapavlov-dremio
I reviewed this issue along with the ongoing draft in PR #1411. Ensuring PreparedStatement.executeBatch() is fully JDBC-compliant by executing each parameter set and draining
PutResultstreams without allocator leaks is a valuable fix.The expected approach entails:
ArrowFlightSqlPreparedStatement/ batch executor.int[]matching the batch size.finallyblocks.BatchUpdateExceptioncontaining partial update counts per JDBC spec.@mykolapavlov-dremio, are you actively working on finalizing PR #1411, or would you welcome assistance / a rebased PR to help get this across the finish line with complete unit tests? Happy to collaborate!