Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 69F8711FE2 for ; Sat, 19 Jul 2014 00:32:39 +0000 (UTC) Received: (qmail 9361 invoked by uid 500); 19 Jul 2014 00:32:38 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 9258 invoked by uid 500); 19 Jul 2014 00:32:38 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 9243 invoked by uid 99); 19 Jul 2014 00:32:38 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 19 Jul 2014 00:32:38 +0000 Date: Sat, 19 Jul 2014 00:32:38 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: dev@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (HBASE-3276) delete followed by a put with the same timestamp MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell resolved HBASE-3276. ----------------------------------- Resolution: Duplicate Assignee: (was: Kannan Muthukkaruppan) A mislaid now-duplicate of more recent issues filed on the same topic. > delete followed by a put with the same timestamp > ------------------------------------------------ > > Key: HBASE-3276 > URL: https://issues.apache.org/jira/browse/HBASE-3276 > Project: HBase > Issue Type: Bug > Reporter: Kannan Muthukkaruppan > > [Note: This issue is relevant only for cases that don't use the default "time" based versions, but provide/manage versions explicitly.] > The fix for HBASE-1485 ensures that if there are multiple puts with the same timestamp the later one wins. > However, if there is a delete for a specific timestamp, then the later put doesn't win. > Say for example the following is the sequence of operations: > put row/col/v1 - value1 > deleteColumn row/col/v1 > put row/col/v1 - value2 > Without the deleteColumn(), HBASE-1485 ensures that "value2" is the winner. > However, with the deleteColumn() thrown into the mix, the delete wins, and one cannot insert a new value at that version. [The only, unsatisfactory, workaround at this point seems to be trigger a major compaction. The major compact would clear the delete marker, and allow new cells to be created with that version again.] > --- > Seems like it might not be too complicated to extend the fix for HBASE-1485 to also respect ordering between delete/put operations. I'll look into this further. -- This message was sent by Atlassian JIRA (v6.2#6252)