[
https://issues.apache.org/jira/browse/PHOENIX-4187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16182824#comment-16182824
]
James Taylor edited comment on PHOENIX-4187 at 9/27/17 4:20 PM:
----------------------------------------------------------------
+1 on the patch with one minor nit: please change System.currentTimeMillis() to
EnvironmentEdgeManager.currentTimeMillis() (the one in
org.apache.phoenix.util). Also, one question: how do we handle when
UPDATE_CACHE_FREQUENCY is used on a table with ROW_TIMESTAMP? If we can force
the update cache from MutationState, that'd be ideal.
bq. How should I handle existing mutable tables with a row timestamp column
that have indexes.
We could automatically drop the indexes during the upgrade step, or throw an
exception when the user tries to upsert rows.
Let's throw an exception when the user tries to upsert rows. That'll be more
evident to the user that they need to take some action (i.e. disable or drop
the index). If we just do it, they may not know until their queries become slow.
Nice work, [~tdsilva]!
was (Author: jamestaylor):
+1 on the patch with one minor nit: please change System.currentTimeMillis() to
EnvironmentEdgeManager.currentTimeMillis() (the one in
org.apache.phoenix.util). Also, one question: how do we handle when
UPDATE_CACHE_FREQUENCY is used on a table with ROW_TIMESTAMP? If we can force
the update cache from MutationState, that'd be ideal.
Nice work, [~tdsilva]!
> Use server timestamp for ROW_TIMESTAMP column when value is not specified
> -------------------------------------------------------------------------
>
> Key: PHOENIX-4187
> URL: https://issues.apache.org/jira/browse/PHOENIX-4187
> Project: Phoenix
> Issue Type: Bug
> Reporter: Samarth Jain
> Assignee: Thomas D'Silva
> Fix For: 4.12.0
>
> Attachments: PHOENIX-4187.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
