hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars George (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3300) force delete option for use cases that explicitly set version/timestamp
Date Thu, 02 Dec 2010 11:00:41 GMT

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

Lars George commented on HBASE-3300:

I have seen this up on mailing list: http://search-hadoop.com/m/amYp31Maiue2/something+wrong+with+hbase+mapreduce&subj=something+wrong+with+hbase+mapreduce

Sounds like the same issue. How do you propose to do this without a major compaction or implicit
timestamps? Purely by the insert order and a specific delete marker?

> force delete option for use cases that explicitly set version/timestamp
> -----------------------------------------------------------------------
>                 Key: HBASE-3300
>                 URL: https://issues.apache.org/jira/browse/HBASE-3300
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Kannan Muthukkaruppan
> Background: For use cases that explicitly set versions, after a delete, it is not possible
to insert values with older versions. So for example if you did a puts (v1) and delete (@
v2), subsequent puts with an older version (e.g., v1) will not take effect since the delete
has a higher version.
> {code}
> #1. PUT(row, col, version1,  old-value)
> #2. DELETE(row, col, version2)
> #3. PUT(row, col, version1, new-value)
> {code}
> The row/col stays deleted, and this is expected behavior since the delete has a higher
> Feature Request: It would be good to provide a "force" delete mechanism -- something
that allows the row or a specific column to be started with a clean slate. i.e. forget about
everything that happened to this item earlier, and lets you start afresh. Without this there
is no good cleanup mechanism for use cases that set versions explicitly.
> [Note: The only workaround for this depends on a subtle implementation detail that major
compactions discard delete markers. So if a major compaction happened between steps #2 &
#3, then you would in fact be able to put a value with an older version.]
> Thoughts?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message