[
https://issues.apache.org/jira/browse/PHOENIX-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219385#comment-17219385
]
Kadir OZDEMIR commented on PHOENIX-6204:
----------------------------------------
We need to bring clarity into when timestamps can be set by clients and
servers. Phoenix does not have a clear architectural principle on this. I have
looked at the current implementation and it is very confusing.
To me, ideally clients should not set the mutation timestamps except for the
specific cases, such as the one this JIRA suggests. If the client sets the
timestamp, then the server should obey it. This require code changes on the
client and server side. For example, the indexing coproc should handle
mutations differently if the timestamps are set by clients. This complicates
index table maintenance greatly. If upsert select uses the timestamps of the
source table, then we need to handle the case where upsert select attempts to
insert older versions of the existing rows to the target table.
I suggest not to add any new behavior until we look at the timestamp issue from
all aspects. I was planning to do this within a month or two but anyone who
wants to tackle it is welcome.
> Provide a way to preserve HBase cell timestamps when running UPSERT SELECT
> statements
> -------------------------------------------------------------------------------------
>
> Key: PHOENIX-6204
> URL: https://issues.apache.org/jira/browse/PHOENIX-6204
> Project: Phoenix
> Issue Type: New Feature
> Affects Versions: 4.15.0
> Reporter: Chinmay Kulkarni
> Priority: Major
>
> Today when we run an UPSERT SELECT statement, the data is upserted with the
> current wall clock time rather than using the timestamp of the cells being
> read via the SELECT statement. In some cases this is favorable, but in others
> it is not.
> Providing a way to do an UPSERT SELECT in which upserts use the HBase
> timestamp of the cells being read is a useful feature.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
