Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D1538200C8C for ; Tue, 6 Jun 2017 22:51:23 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id D0270160BD3; Tue, 6 Jun 2017 20:51:23 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D106F160BB7 for ; Tue, 6 Jun 2017 22:51:22 +0200 (CEST) Received: (qmail 56676 invoked by uid 500); 6 Jun 2017 20:51:21 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 56647 invoked by uid 99); 6 Jun 2017 20:51:21 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Jun 2017 20:51:21 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 98A32C047C for ; Tue, 6 Jun 2017 20:51:20 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id LIRgNg_PoRKO for ; Tue, 6 Jun 2017 20:51:19 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 34AC15F36F for ; Tue, 6 Jun 2017 20:51:19 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 8090DE0A2F for ; Tue, 6 Jun 2017 20:51:18 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 38D9B21B51 for ; Tue, 6 Jun 2017 20:51:18 +0000 (UTC) Date: Tue, 6 Jun 2017 20:51:18 +0000 (UTC) From: "James Taylor (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: 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 X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 06 Jun 2017 20:51:24 -0000 [ https://issues.apache.org/jira/browse/PHOENIX-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16039604#comment-16039604 ] James Taylor commented on PHOENIX-3907: --------------------------------------- That seems reasonable, [~tdsilva]. Any holes with the upsert select or delete case where we need the time stamp set? Or if SCN is set? Would another option be to add a currentTime member variable to TableRef and capture the timestamp from the result there? I think you could the PTable there to check the updateCacheFrequency value. > 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)