phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davide Vergari (Jira)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-6481) Strange behavior in upserting-deleting-upserting when primary key contains a ROW TIMESTAMP field
Date Fri, 28 May 2021 08:36:00 GMT

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

Davide  Vergari updated PHOENIX-6481:
-------------------------------------
    Description: 
Hello,

we found a strange behavior in upserting -> deleting -> upserting again a row in a phoenix
table when the primary key contains a ROW_TIMESTAMP field.

 

If you upsert a record, than you delete this record and upsert the same record again, the
latest operation does not take effect.

 

Steps to reproduce:

 
{code:java}
0: jdbc:phoenix:> drop table if exists t1;
No rows affected (0.66 seconds)
0: jdbc:phoenix:> create table t1 (c1 timestamp not null, c2 integer constraint pk primary
key (c1 row_timestamp));
No rows affected (0.75 seconds)
0: jdbc:phoenix:> upsert into t1 (c1, c2) values (to_timestamp('2021-05-28 00:00:00.000',
'yyyy-MM-dd HH:mm:SS.ssss', 'UTC+2'), 1);
1 row affected (0.008 seconds)
0: jdbc:phoenix:> select * from t1;
+--------------------------+-----+
|            C1            | C2  |
+--------------------------+-----+
| 2021-05-28 00:00:00.000  | 1   |
+--------------------------+-----+
1 row selected (0.041 seconds)
0: jdbc:phoenix:> delete from t1 where c1 = to_timestamp('2021-05-28 00:00:00.000', 'yyyy-MM-dd
HH:mm:SS.ssss', 'UTC+2');
1 row affected (0.007 seconds)
0: jdbc:phoenix:> upsert into t1 (c1, c2) values (to_timestamp('2021-05-28 00:00:00.000',
'yyyy-MM-dd HH:mm:SS.ssss', 'UTC+2'), 1);
1 row affected (0.007 seconds)
0: jdbc:phoenix:> select * from t1;
+-----+-----+
| C1  | C2  |
+-----+-----+
+-----+-----+
No rows selected (0.027 seconds)
0: jdbc:phoenix:> 

{code}
If I upsert a new row with a different ROW_TIMESTAMP everything works as expected.

 

The same issue there is also if the PK is a composed one, but with a ROW_TIMESTAMP in it.

 

I'm using HBase 2.0.2 and Phoenix 5.0.0-Hbase-2.0

{color:#6897bb} {color}

  was:
Hello,

we found a strange behavior in upserting -> deleting -> upserting again a row in a phoenix
table when the primary key contains a ROW_TIMESTAMP field.

 

If you upsert a record, than you delete this record and upsert the same record again, the
latest operation does not take effect.

 

Steps to reproduce:

 
{code:java}
0: jdbc:phoenix:> drop table if exists t1;
No rows affected (0.66 seconds)
0: jdbc:phoenix:> create table t1 (c1 timestamp not null, c2 integer constraint pk primary
key (c1 row_timestamp));
No rows affected (0.75 seconds)
0: jdbc:phoenix:> upsert into t1 (c1, c2) values (to_timestamp('2021-05-28 00:00:00.000',
'yyyy-MM-dd HH:mm:SS.ssss', 'UTC+2'), 1);
1 row affected (0.008 seconds)
0: jdbc:phoenix:> select * from t1;
+--------------------------+-----+
|            C1            | C2  |
+--------------------------+-----+
| 2021-05-28 00:00:00.000  | 1   |
+--------------------------+-----+
1 row selected (0.041 seconds)
0: jdbc:phoenix:> delete from t1 where c1 = to_timestamp('2021-05-28 00:00:00.000', 'yyyy-MM-dd
HH:mm:SS.ssss', 'UTC+2');
1 row affected (0.007 seconds)
0: jdbc:phoenix:> upsert into t1 (c1, c2) values (to_timestamp('2021-05-28 00:00:00.000',
'yyyy-MM-dd HH:mm:SS.ssss', 'UTC+2'), 1);
1 row affected (0.007 seconds)
0: jdbc:phoenix:> select * from t1;
+-----+-----+
| C1  | C2  |
+-----+-----+
+-----+-----+
No rows selected (0.027 seconds)
0: jdbc:phoenix:> 

{code}
If I upsert a new row with a different ROW_TIMESTAMP everything works as expected.

 

The same issue there is also if the PK is a composed one, but with a ROW_TIMESTAMP in it


> Strange behavior in upserting-deleting-upserting when primary key contains a ROW TIMESTAMP
field
> ------------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-6481
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6481
>             Project: Phoenix
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 5.0.0
>            Reporter: Davide  Vergari
>            Priority: Major
>
> Hello,
> we found a strange behavior in upserting -> deleting -> upserting again a row in
a phoenix table when the primary key contains a ROW_TIMESTAMP field.
>  
> If you upsert a record, than you delete this record and upsert the same record again,
the latest operation does not take effect.
>  
> Steps to reproduce:
>  
> {code:java}
> 0: jdbc:phoenix:> drop table if exists t1;
> No rows affected (0.66 seconds)
> 0: jdbc:phoenix:> create table t1 (c1 timestamp not null, c2 integer constraint pk
primary key (c1 row_timestamp));
> No rows affected (0.75 seconds)
> 0: jdbc:phoenix:> upsert into t1 (c1, c2) values (to_timestamp('2021-05-28 00:00:00.000',
'yyyy-MM-dd HH:mm:SS.ssss', 'UTC+2'), 1);
> 1 row affected (0.008 seconds)
> 0: jdbc:phoenix:> select * from t1;
> +--------------------------+-----+
> |            C1            | C2  |
> +--------------------------+-----+
> | 2021-05-28 00:00:00.000  | 1   |
> +--------------------------+-----+
> 1 row selected (0.041 seconds)
> 0: jdbc:phoenix:> delete from t1 where c1 = to_timestamp('2021-05-28 00:00:00.000',
'yyyy-MM-dd HH:mm:SS.ssss', 'UTC+2');
> 1 row affected (0.007 seconds)
> 0: jdbc:phoenix:> upsert into t1 (c1, c2) values (to_timestamp('2021-05-28 00:00:00.000',
'yyyy-MM-dd HH:mm:SS.ssss', 'UTC+2'), 1);
> 1 row affected (0.007 seconds)
> 0: jdbc:phoenix:> select * from t1;
> +-----+-----+
> | C1  | C2  |
> +-----+-----+
> +-----+-----+
> No rows selected (0.027 seconds)
> 0: jdbc:phoenix:> 
> {code}
> If I upsert a new row with a different ROW_TIMESTAMP everything works as expected.
>  
> The same issue there is also if the PK is a composed one, but with a ROW_TIMESTAMP in
it.
>  
> I'm using HBase 2.0.2 and Phoenix 5.0.0-Hbase-2.0
> {color:#6897bb} {color}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message