Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 15 Oct 2011 12:43:11 +0000 (UTC)
From: "Ted Yu (Commented) (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <965855323.17046.1318682591861.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <77903496.5372.1317683553967.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-4536) Allow CF to retain deleted rows
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Ted Yu commented on HBASE-4536:
-------------------------------

bq. I was also thinking about an enum for the scan type too. There are seven different cases:
Since the cases span multiple dimensions (compaction, keeping deleted rows), enum is not good candidate.

How about introducing MatcherConfig so that new parameters can be added relatively easily in the future ?
                
> Allow CF to retain deleted rows
> -------------------------------
>
>                 Key: HBASE-4536
>                 URL: https://issues.apache.org/jira/browse/HBASE-4536
>             Project: HBase
>          Issue Type: New Feature
>          Components: regionserver
>    Affects Versions: 0.92.0
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>             Fix For: 0.94.0
>
>
> Parent allows for a cluster to retain rows for a TTL or keep a minimum number of versions.
> However, if a client deletes a row all version older than the delete tomb stone will be remove at the next major compaction (and even at memstore flush - see HBASE-4241).
> There should be a way to retain those version to guard against software error.
> I see two options here:
> 1. Add a new flag HColumnDescriptor. Something like "RETAIN_DELETED".
> 2. Folds this into the parent change. I.e. keep minimum-number-of-versions of versions even past the delete marker.
> #1 would allow for more flexibility. #2 comes somewhat naturally with parent (from a user viewpoint)
> Comments? Any other options?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira