[
https://issues.apache.org/jira/browse/HBASE-11292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14281227#comment-14281227
]
Lars Hofhansl commented on HBASE-11292:
---------------------------------------
Let's revive this. What I have been proposing in a meeting we had was an "UNDO"
cell type. Undo would sort before deletes and simply undo the next cell that
immediately follows in sort order. Another UNDO with the same TS would undo the
UNDO, as so on.
I do not think we want to undo Puts, we have deletes for that.
So we would need to two new Cell type: undo delete (for version and column
delete markers) and undo delete family for family delete markers.
I think my comments on family delete bloom filters above are misguided. At
worst we'd see a performance degradation for seeking to the beginning of the
row when that is not necessary when the delete is undone.
The only trick part here is that all seeking before a row or column or to the
end of a row or column need to be seeking correctly with UNDO cell types.
> 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)
