Details
-
New Feature
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
Description
This is the client counter part of MDEV-30366: permit returning individual results.
This will permit to :
return exact all auto increment id
return individual update rows, permitting "Optimistic locking" batching.
This will permit to have a transparent use of BULK compare to unitary sending all updates.
see c/c implementation https://github.com/mariadb-corporation/mariadb-connector-c/commit/abce07da2ad256c5be2b9d7cc222cccb8cdc6163
(new capability MARIADB_CLIENT_BULK_UNIT_RESULTS + bulk flag STMT_BULK_FLAG_SEND_UNIT_RESULTS)
Attachments
Issue Links
- is caused by
-
-
- Closed
-
Activity
JDBC permit current behavior, but this cause various issues in java use, it will be the same for c++. This change is a perfect fit for what people expect.
Result will be the similar, but more precise :
PrepareStatment `int[] executeBatch()` will still return int[], but it will return individual result changes like [1,1] in place of [Statement.SUCCESS_NO_INFO, Statement.SUCCESS_NO_INFO]
Same, PrepareStatement `ResultSet getGeneratedKeys()` will still return a resultset, but in place of containing only first generated id, it will contain all generated ids.
An option can permit to get current behavior for compatibility. So a minor change, but not major.
I wouldn't do an option for that. It comes with a new server version. If people move to new server version, and their application expects SUCCESS_NO_INFO as successful operation condition, well, time to fix your application. We ain't doing no wrong - if we can't provide id's, then we return SUCCESS_NO_INFO, if we can, then we can. Besides there is not that many c++ applications out there comparing to java
Would this change be an incompatibility change?