virajjasani commented on code in PR #2199:
URL: https://github.com/apache/phoenix/pull/2199#discussion_r2164407508
##########
phoenix-core-client/src/main/java/org/apache/phoenix/jdbc/PhoenixPreparedStatement.java:
##########
@@ -215,6 +215,28 @@ private void preExecuteUpdate() throws SQLException {
}
}
+ /**
+ * Executes the given SQL statement similar to JDBC API executeUpdate()
but also returns the
+ * old row (before update) as Result object back to the client. This must
be used with
+ * auto-commit Connection. This makes the operation atomic.
+ * Return the old row (state before update) regardless of whether the
update is
+ * successful or not.
+ *
+ * @return The pair of int and ResultSet, where int represents value 1 for
successful row update
+ * and 0 for non-successful row update, and ResultSet represents the old
state of the row.
+ * @throws SQLException If the statement cannot be executed.
+ */
+ // Note: Do Not remove this, it is expected to be used by downstream
applications
+ public Pair<Integer, ResultSet> executeAtomicUpdateReturnOldRow() throws
SQLException {
Review Comment:
I think the API contract is very clean with this. Yes boolean based single
method is also not bad, but the method name would not be self explanatory, one
will have to look up the meaning of boolean. It Enum was exposed, probably
would have been better than boolean.
Given that we only need new row and old row contracts, this is not expected
to change and the method names are quite self explanatory. One has to make
intentionally bad decision in using oldRow() for new row behaviour or newRow()
for old row behaviour. Whereas boolean based method can be copied from one
place to another and one might miss checking the meaning of boolean.
I don't mind making single method, it's not difficult either, but with two
methods instead of one, I am finding it much cleaner.
--
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...@phoenix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
