hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kannan Muthukkaruppan (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 16:51:11 GMT

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

Kannan Muthukkaruppan commented on HBASE-3300:

Lars: Had a discussion up in IRC with Ryan yesterday. Was originally thinking perhaps a new
type of delete marker which resolves based on maxSeqId metadata stored in HFiles. But Ryan
wants to solve multiple related problems--- and his solution proposed for HBASE-2856 (additional
sequenceID (memstoreTS'ish timestamp)) stored with each KV should handle not only the original
issue described in HBASE-2856 but also the two delete issues (HBASE-3276 and this one). The
HBASE-2856 proposal sounds like the way to go.

> 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