virajjasani commented on code in PR #2199:
URL: https://github.com/apache/phoenix/pull/2199#discussion_r2163130430
##########
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:
For the import, I only meant that it is usually expected for Phoenix
downstreamers to import PhoenixConnection or PhoenixStatement or
PhoenixPreparedStatement. However, anything else e.g. Tuple, MutationState etc
is not expected to be imported or used in anyway.
> An import on PhoenixStatement or PhoenixPreparedStatement is already
needed right? Is there a difference between a single import vs two imports?
Since you are confident of having only two types, an alternative is to use a
boolean param which can then be translated to the enum inside the method.
That's also nice idea, but my intention was to try to follow the method
signature of executeUpdate(). As part of Kadir's suggestion, the method
signature was changed to `executeAtomicUpdateReturnRow()` from
`executeUpdateReturnRow()` with PHOENIX-7462. The intention was to keep as
close to `executeUpdate()` as possible :)
--
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
