[
https://issues.apache.org/jira/browse/PHOENIX-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17551897#comment-17551897
]
Kadir Ozdemir commented on PHOENIX-6481:
----------------------------------------
[~richardantal], This is the expected behavior. If you provide the row
timestamp then the server uses it as the timestamp for the row. If you do not
provide it then the server assigns its current time value as the row timestamp.
If you delete a row, the timestamp of the delete marker is the current time of
the server. This delete marker will be effective until the next major
compaction. Because of the delete marker, if you use the same row timestamp for
the next row, the row will not be visible. Similarly, you should not be able
to delete a row with a row timestamp in future.
> 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.20.7#820007)
