hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HBase Review Board (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-3276) delete followed by a put with the same timestamp
Date Fri, 26 Nov 2010 15:49:18 GMT

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

HBase Review Board commented on HBASE-3276:

Message from: "Pranav Khaitan" <pranavkhaitan@gmail.com>

This is an automatically generated e-mail. To reply, visit:

Review request for hbase, Jonathan Gray and Kannan Muthukkaruppan.


This is a design change suggested in HBASE-3276 so adequate thought should be given before

The main code change is just one line which is to ignore key type while doing KV comparisons.
When the key type is ignored, then all the keys for the same timestamp are sorted according
the order in which they were interested. It is still ensured that the delete family and delete
column will be at the top because they have the default column name and default timestamp.

This addresses bug HBASE-3276.


  trunk/src/main/java/org/apache/hadoop/hbase/KeyValue.java 1039233 
  trunk/src/test/java/org/apache/hadoop/hbase/regionserver/KeyValueScanFixture.java 1039233

  trunk/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreScanner.java 1039233 

Diff: http://review.cloudera.org/r/1252/diff


Test cases added. Since there is a change in semantics, some previous tests were failing because
of this change. Those tests have been modified to test the newer behavior.



> delete followed by a put with the same timestamp
> ------------------------------------------------
>                 Key: HBASE-3276
>                 URL: https://issues.apache.org/jira/browse/HBASE-3276
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Kannan Muthukkaruppan
>            Assignee: Kannan Muthukkaruppan
> [Note: This issue is relevant only for cases that don't use the default "time" based
versions, but provide/manage versions explicitly.]
> The fix for HBASE-1485 ensures that if there are multiple puts with the same timestamp
the later one wins.
> However, if there is a delete for a specific timestamp, then the later put doesn't win.

> Say for example the following is the sequence of operations:
> put                         row/col/v1 - value1
> deleteColumn     row/col/v1
> put                         row/col/v1 - value2
> Without the deleteColumn(), HBASE-1485 ensures that "value2" is the winner.
> However, with the deleteColumn() thrown into the mix, the delete wins, and one cannot
insert a new value at that version. [The only, unsatisfactory, workaround at this point seems
to be trigger a major compaction. The major compact would clear the delete marker, and allow
new cells to be created with that version again.] 
> ---
> Seems like it might not be too complicated to extend the fix for HBASE-1485 to also respect
ordering between delete/put operations. I'll look into this further.

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

View raw message