[
https://issues.apache.org/jira/browse/HBASE-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14323681#comment-14323681
]
James Taylor commented on HBASE-11292:
--------------------------------------
[~lhofhansl] - that's a good point. What about even ignoring a Put? Does the
Tephra TransactionVisibilityFilter[1] handle ignoring a Put such that an
earlier Put would be seen? Do all scans have to be raw scans, [~ghelmling]?
[1]
https://github.com/caskdata/tephra/blob/develop/tephra-hbase-compat-0.98/src/main/java/co/cask/tephra/hbase98/coprocessor/TransactionVisibilityFilter.java
> 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)
