Davide Vergari created PHOENIX-6481:
----------------------------------------
Summary: 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
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
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
