Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 16 May 2014 23:56:17 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12677877.1383775999440.373239.1400284577479@arcas>
In-Reply-To: <JIRA.12677877.1383775999440@arcas>
References: <JIRA.12677877.1383775999440@arcas>
Subject: [jira] [Commented] (HBASE-9905) Enable using seqId as timestamp
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lars Hofhansl commented on HBASE-9905:
--------------------------------------

What about features like TTL that based on wall clock time? Are we going to unsupport them (unless the client sets the TSs)?

> Enable using seqId as timestamp 
> --------------------------------
>
>                 Key: HBASE-9905
>                 URL: https://issues.apache.org/jira/browse/HBASE-9905
>             Project: HBase
>          Issue Type: New Feature
>            Reporter: Enis Soztutar
>
> This has been discussed previously, and Lars H. was mentioning an idea from the client to declare whether timestamps are used or not explicitly. 
> The problem is that, for data models not using timestamps, we are still relying on clocks to order the updates. Clock skew, same milisecond puts after deletes, etc can cause unexpected behavior and data not being visible.  
> We should have a table descriptor / family property, which would declare that the data model does not use timestamps. Then we can populate this dimension with the seqId, so that global ordering of edits are not effected by wall clock. 
> For example, META will use this. 
> Once we have something like this, we can think of making it default for new tables, so that the unknowing user will not shoot herself in the foot. 


--
This message was sent by Atlassian JIRA
(v6.2#6252)