[
https://issues.apache.org/jira/browse/HBASE-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119923#comment-13119923
]
Lars Hofhansl commented on HBASE-4536:
--------------------------------------
Started to look at the code.
Scanning now has three different scenarios:
# Normal scan. Under all circumstanced filter deleted rows (unless it's a past
scan, of course). Do not return delete markers.
# Minor compaction. If min versions is not set, follow current behavior (filter
deleted rows, keep delete markers). If min versions is set, keep deleted rows,
treat delete markers as normal rows (but do not count them as versions). I.e.
delete markers are subject to maxversions, expiration, etc.
# Major compaction. If min versions is not set, follow current behavior (filter
deleted rows, remove delete markers, like #1). If min versions is set, keep
deleted rows, treat delete markers as normal rows (again, do not count them as
versions).
In all three cases rows past max versions or expired rows past min versions
will be filtered out.
Jon could reuse scan type #2 or #3 for his needs, I think.
> Allow CF to retain deleted rows
> -------------------------------
>
> Key: HBASE-4536
> URL: https://issues.apache.org/jira/browse/HBASE-4536
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Affects Versions: 0.92.0
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.92.0, 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
