[jira] [Comment Edited] (PHOENIX-6420) Wrong result when conditional and regular upserts are passed in the same commit batch

["Kadir Ozdemir (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304386#comment-17304386 ] 

Kadir Ozdemir edited comment on PHOENIX-6420 at 3/18/21, 7:32 PM:
------------------------------------------------------------------

[~tkhurana] Thank you for clearly identifying and documenting the problem. Also I would like to thank [~jisaac] for pointing out that it may not be safe to merge mutations on the client side for conditional updates.


was (Author: kadir):
[~tkhurana] Thank you for clearly identifying and documenting the problem. Also I would like to thank [~jisaac] to pointing out that it may not be safe to merge mutations on the client side for conditional updates.

> 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
>            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)