[
https://issues.apache.org/jira/browse/PHOENIX-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Yuan Jiang reassigned PHOENIX-6714:
-------------------------------------------
Assignee: Jing Yu (was: Tanuj Khurana)
> Return update status from Conditional Upserts
> ---------------------------------------------
>
> Key: PHOENIX-6714
> URL: https://issues.apache.org/jira/browse/PHOENIX-6714
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Tanuj Khurana
> Assignee: Jing Yu
> Priority: Major
>
> {code:java}
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123);
> 1 row affected (0.005 seconds)
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123) on duplicate key
> ignore;
> 1 row affected (0.008 seconds){code}
> Even when the row already exists, we return “1” row updated.
> {code:java}
> 0: jdbc:phoenix:localhost> upsert into T1 values ('cd', 123) on duplicate key
> update
> val=val;
> 1 row affected (0.01 seconds) {code}
> In this case, the value of column ‘val’ does not change so we could return
> “0“ to denote that fact. I mentioned ”could“ because as per the current
> implementation even though from the application perspective the value of the
> column is the same, from HBase perspective we are doing another PUT mutation
> which adds another version to the underlying cell and updates the cell
> timestamp. We also update the timestamp of the empty cell. So, technically
> this is an update from HBase perspective.
> Referring MYSQL which has similar conditional update constructs, its
> documentation says: “ With ON DUPLICATE KEY UPDATE, the affected-rows value
> per row is 1 if the row is inserted as a new row, 2 if an existing row is
> updated, and 0 if an existing row is set to its current values.”
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
