phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas D'Silva (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3907) Use LATEST_TIMESTAMP when UPDATE_CACHE_FREQUENCY is not zero
Date Tue, 06 Jun 2017 19:57:18 GMT


Thomas D'Silva commented on PHOENIX-3907:


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. 

-            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;

> ------------------------------------------------------------
>                 Key: PHOENIX-3907
>                 URL:
>             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

View raw message