Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Tue, 6 Jun 2017 19:57:18 +0000 (UTC)
From: "Thomas D'Silva (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13076934.1496427388000.9916.1496779038227@Atlassian.JIRA>
In-Reply-To: <JIRA.13076934.1496427388000@Atlassian.JIRA>
References: <JIRA.13076934.1496427388000@Atlassian.JIRA> <JIRA.13076934.1496427388882@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-3907) Use LATEST_TIMESTAMP when
 UPDATE_CACHE_FREQUENCY is not zero
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 06 Jun 2017 19:57:22 -0000


    [ 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)