[ 
https://issues.apache.org/jira/browse/PHOENIX-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039533#comment-16039533
 ] 

Thomas D'Silva commented on PHOENIX-3907:
-----------------------------------------

[~jamestaylor]

StatementContext.getCurrentTime() sets the current time based on the current 
table reference. If I modify MetadataClient.updateCache to set the mutation 
result time to UNSET_TIMESTAMP, then we lose the current date optimization that 
prevents the rpc. I don't see an easy way to get the statement context in 
updateCache.
Instead of modifying update cache, should I just modify MutationState.validate 
to set the server time stamp to UNSET_TIMESTAMP if UPDATE_CACHE_FREQUENCY is 
set ? This will then be used to generate the mutations. 

{code}
-            serverTimeStamp = timestamp;
+            // if UPDATE_CACHE_FREQUENCY is set the mutation result time is 
UNSET_TIMESTAMP *except* when the cached table expires
+            // so set the server time stamp to UNSET_TIMESTAMP to be consisent
+            serverTimeStamp = table.getUpdateCacheFrequency()!=0 ? 
QueryConstants.UNSET_TIMESTAMP : timestamp;
{code}

> Use LATEST_TIMESTAMP when UPDATE_CACHE_FREQUENCY is not zero
> ------------------------------------------------------------
>
>                 Key: PHOENIX-3907
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3907
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>         Attachments: PHOENIX-3907.patch
>
>
> For non transactional tables, currently with UPDATE_CACHE_FREQUENCY, we'll 
> use LATEST_TIMESTAMP *most* of the time, until the cached entity expires, in 
> which case we'll use the server timestamp. This seems a bit strange and 
> inconsistent. Instead (for non transactional tables), we should always use 
> LATEST_TIMESTAMP if UPDATE_CACHE_FREQUENCY is non zero, with the exception of 
> the corner case for UPSERT SELECT and DELETE where the same table is being 
> read and written to (see changes to FromCompiler for PHOENIX-3823).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to