Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Message-ID: <1062506117.1237222310905.JavaMail.jira@brutus>
Date: Mon, 16 Mar 2009 09:51:50 -0700 (PDT)
From: "stack (JIRA)" <jira@apache.org>
To: hbase-dev@hadoop.apache.org
Subject: [jira] Commented: (HBASE-1249) Rearchitecting of server, client,
 API, key format, etc for 0.20
In-Reply-To: <728871099.1236620030451.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

stack commented on HBASE-1249:
------------------------------

.bq -1 Unless there is another "version" field. We have an application that makes extensive use of timestamp at Powerset.

We should review our internal app.  I don't believe our application guards against timestamps' being set non-chronologically.

On the timestamping issue, we speak with forked tongue.  We allow setting it all over our API but we only internally support chronologically-ordered stamps.  If a user enters out-of-order timestamps, results are indeterminate

> Rearchitecting of server, client, API, key format, etc for 0.20
> ---------------------------------------------------------------
>
>                 Key: HBASE-1249
>                 URL: https://issues.apache.org/jira/browse/HBASE-1249
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: Jonathan Gray
>            Priority: Blocker
>             Fix For: 0.20.0
>
>
> To discuss all the new and potential issues coming out of the change in key format (HBASE-1234): zero-copy reads, client binary protocol, update of API (HBASE-880), server optimizations, etc...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.