Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 5 Feb 2015 23:01:35 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12718202.1401816132000.272843.1423177295755@Atlassian.JIRA>
In-Reply-To: <JIRA.12718202.1401816132000@Atlassian.JIRA>
References: <JIRA.12718202.1401816132000@Atlassian.JIRA>
 <JIRA.12718202.1401816132807@arcas>
Subject: [jira] [Commented] (HBASE-11292) Add an "undelete" operation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Lars Hofhansl commented on HBASE-11292:
---------------------------------------

I will think about this in earnest during the next few days.

Related: A scan coprocessor can currently not ignore delete markers (without reimplementing the entire delete marker logic). I am not about a good interface for this (seems like we need a pass down a list of excluded timeranges). [~ghelmling], any ideas?

> Add an "undelete" operation
> ---------------------------
>
>                 Key: HBASE-11292
>                 URL: https://issues.apache.org/jira/browse/HBASE-11292
>             Project: HBase
>          Issue Type: New Feature
>          Components: Deletes
>            Reporter: Gary Helmling
>              Labels: Phoenix
>
> While column families can be configured to keep deleted cells (allowing time range queries to still retrieve those cells), deletes are still somewhat unique in that they are irreversible operations.  Once a delete has been issued on a cell, the only way to "undelete" it is to rewrite the data with a timestamp newer than the delete.
> The idea here is to add an "undelete" operation, that would make it possible to cancel a previous delete.  An undelete operation will be similar to a delete, in that it will be written as a marker ("tombstone" doesn't seem like the right word).  The undelete marker, however, will sort prior to a delete marker, canceling the effect of any following delete.
> In the absence of a column family configured to KEEP_DELETED_CELLS, we can't be sure if a prior delete marker and the effected cells have already been garbage collected.  In this case (column family not configured with KEEP_DELETED_CELLS) it may be necessary for the server to reject undelete operations to avoid creating the appearance of a client contact for undeletes that can't reliably be honored.
> I think there are additional subtleties of the implementation to be worked out, but I'm also interested in a broader discussion of interest in this capability.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)