[
https://issues.apache.org/jira/browse/PHOENIX-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035426#comment-16035426
]
Thomas D'Silva commented on PHOENIX-3907:
-----------------------------------------
[~jamestaylor]
You are referring to setting the MetaDataMutationResult mutation time to
QueryConstants.UNSET_TIMESTAMP when update cache frequency is set and the
cached entity hasn't expired right ? Later on when we create mutations if the
timestamp is set to UNSET_TIMESTAMP we use the LATEST_TIMESTAMP.
{code}
// Do not make rpc to getTable if
// 1. table is a system table
// 2. table was already resolved as of that timestamp
if (table != null && !alwaysHitServer
&& (systemTable || resolvedTimestamp == tableResolvedTimestamp
|| connection.getMetaDataCache().getAge(tableRef) <
table.getUpdateCacheFrequency())) {
return new
MetaDataMutationResult(MutationCode.TABLE_ALREADY_EXISTS,
QueryConstants.UNSET_TIMESTAMP, table);
}
{code}
If the cached entry expired the MetaDataMutationResult mutation time is set to
the server timestamp (same as the behavior of tables without
UPDATE_CACHE_FREQUENCY set). I think it makes sense to be consistent and always
set the MetaDataMutationResult mutation time to QueryConstants.UNSET_TIMESTAMP
if UPDATE_CACHE_FREQUENCY is set (except for the UPSERT SELECT/ DELETE corner
case when the alwaysHitServer flag is set to true).
> 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
>
> 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)
