You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Tanuj Khurana (Jira)" <ji...@apache.org> on 2021/03/18 19:15:00 UTC

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

     [ https://issues.apache.org/jira/browse/PHOENIX-6420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tanuj Khurana updated PHOENIX-6420:
-----------------------------------
    Description: 
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.

  was:
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.


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