[
https://issues.apache.org/jira/browse/HBASE-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12965911#action_12965911
]
ryan rawson commented on HBASE-3276:
------------------------------------
I'm worried that an implicit ordering opens us to problems in the future. The
kind that involve "i lost my data and there is no way to recover it".
To that end, I propose we implement HBASE-2856, specifically my comment
https://issues.apache.org/jira/browse/HBASE-2856?focusedCommentId=12899119&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12899119
which talks about bringing the memstoreTS (ish, an equivalent but not quite
identical value) down into the HFile. It will have many benefits, including
fixing this JIRA, and also fixing the ACID stuff that has been waylaid for lack
of this change.
> 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.
