[
https://issues.apache.org/jira/browse/HBASE-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12936134#action_12936134
]
HBase Review Board commented on HBASE-3276:
-------------------------------------------
Message from: "Pranav Khaitan" <[email protected]>
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1252/
-----------------------------------------------------------
(Updated 2010-11-26 16:02:47.462170)
Review request for hbase, Jonathan Gray and Kannan Muthukkaruppan.
Summary (updated)
-------
This is a design change suggested in HBASE-3276 so adequate thought should be
given before proceeding.
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 inserted. 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.
http://issues.apache.org/jira/browse/HBASE-3276
Diffs
-----
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
Testing
-------
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.
Thanks,
Pranav
> 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.
