[
https://issues.apache.org/jira/browse/PHOENIX-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17899363#comment-17899363
]
Viraj Jasani commented on PHOENIX-7462:
---------------------------------------
That is COUNT(*) case, but this case is different. Here, we expect to return
ResultSet as if someone queried "SELECT * FROM <table>" so that all column
indexes and column names remain same and user can expect to retrieve the column
values accordingly.
Any custom modification to ResultSet looks confusing for user for this case.
For COUNT(*), it makes sense because user is expecting count value, but same is
not the case here. Specifically the integer value here holds crucial
information, similar to JDBC executeUpdate() API.
> Single row Atomic Upsert/Delete returning result should return ResultSet
> ------------------------------------------------------------------------
>
> Key: PHOENIX-7462
> URL: https://issues.apache.org/jira/browse/PHOENIX-7462
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Viraj Jasani
> Assignee: Viraj Jasani
> Priority: Major
>
> PHOENIX-7398 introduces new PhoenixStatement API to return row for
> Atomic/Conditional Upserts. Phoenix already supports Upserts as Atomic
> operation by using ON DUPLICATE KEY clause.
> Similarly, PHOENIX-7411 and PHOENIX-7434 introduce Atomic Delete support for
> the single row deletion. It returns result (row) back to the client (using
> new API) only if the given client initiated Delete operation deleted the row
> when the row was alive. In the context of atomicity, this means that the
> delete operation is already idempotent and will continue to be idempotent,
> however the client that was able to successfully delete the row by taking
> lock on the live row (row without delete marker) is expected to be the only
> client that can retrieve the old row result back.
> The purpose of this Jira is to update the API signature for the
> PhoenixStatement API such that the abstract level ResultSet object can be
> returned for the returned row instead of Tuple object.
> *Old API signature:*
> {code:java}
> /**
> * Executes the given SQL statement similar to JDBC API executeUpdate() but
> also returns the
> * updated or non-updated row as Result object back to the client. This must
> be used with
> * auto-commit Connection. This makes the operation atomic.
> * If the row is successfully updated, return the updated row, otherwise if
> the row
> * cannot be updated, return non-updated row.
> *
> * @param sql The SQL DML statement, UPSERT or DELETE for Phoenix.
> * @return The pair of int and Tuple, where int represents value 1 for
> successful row
> * update and 0 for non-successful row update, and Tuple represents the state
> of the row.
> * @throws SQLException If the statement cannot be executed.
> */
> public Pair<Integer, Tuple> executeUpdateReturnRow(String sql) throws
> SQLException {{code}
> *New API signature:*
> {code:java}
> /**
> * Executes the given SQL statement similar to JDBC API executeUpdate() but
> also returns the
> * updated or non-updated row as ResultSet object back to the client. This
> must be used with
> * auto-commit Connection. This makes the operation atomic.
> * If the row is successfully updated, return the updated row, otherwise if
> the row
> * cannot be updated, return non-updated row.
> *
> * @param sql The SQL DML statement, UPSERT or DELETE for Phoenix.
> * @return The map entry 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
> state of the row.
> * @throws SQLException If the statement cannot be executed.
> */
> public Map.Entry<Integer, ResultSet> executeAtomicUpdateReturnRow(String sql)
> throws SQLException { {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
