[ https://issues.apache.org/jira/browse/PHOENIX-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tanuj Khurana updated PHOENIX-6420: ----------------------------------- Affects Version/s: 5.0.0 4.16.0 > Wrong result when conditional and regular upserts are passed in the same > commit batch > ------------------------------------------------------------------------------------- > > Key: PHOENIX-6420 > URL: https://issues.apache.org/jira/browse/PHOENIX-6420 > Project: Phoenix > Issue Type: Bug > Affects Versions: 5.0.0, 4.16.0 > Reporter: Tanuj Khurana > Assignee: Tanuj Khurana > Priority: Major > > Consider this example: > {code:java} > CREATE TABLE T1 (k integer not null primary key, v1 bigint, v2 bigint); > {code} > Now consider this batch: > {code:java} > UPSERT INTO T1 VALUES(0,0,1); > UPSERT INTO T1 VALUES(0,1,1) ON DUPLICATE KEY UPDATE v1 = v1 + 2; > commit(); > {code} > Expected row state: 0, 2, 1 > Actual: 0, 2, 0 > The value of the column (v2) not updated in the conditional expression > remains default. It's value should have been the one set in the regular > upsert in the batch. > Now, the row exists. Consider another batch of updates > {code:java} > UPSERT INTO T1 VALUES(0, 7, 4); > UPSERT INTO T1 VALUES(0,1,1) ON DUPLICATE KEY UPDATE v1 = v1 + 2; > commit(); > {code} > Expected row state: 0,2,1 -> 0, 9, 4 > Actual: 0,2,0 -> 0, 4, 0 > The conditional update expression is evaluated and applied on the row state > already committed instead of on the regular update in the same batch. Also, > v2 still remains 0 (the default value). > Now consider the case of a partial regular update following a conditional > update: > {code:java} > UPSERT INTO T1 (k, v2) VALUES(0,100) ON DUPLICATE KEY UPDATE v1 = v1 + 2; > UPSERT INTO T1 (k, v2) VALUES (0,125); > commit(); > {code} > Expected row state: 0, 9, 4 -> 0, 11, 125 > Actual: 0, 4, 0 -> 0, 4, 125 > Only the regular update is applied and the conditional update is completely > ignored. -- This message was sent by Atlassian Jira (v8.3.4#803005)