[
https://issues.apache.org/jira/browse/HBASE-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209085#comment-13209085
]
Lars Hofhansl commented on HBASE-5241:
--------------------------------------
If two things happen at the same time there *is* no right order. The fact that
we have limited timer resolution is not that relevant here.
We just discussed another scenario internally here, were we have application
level replicas of a table. One way to do this is have the client write to two
HBase clusters and also have a catchup background task which copies older
(before we started the dual-writing) cells to the replica. We will use this a
lot to catch up standby clusters, etc. This would also not work any longer.
Anyway, if there are other committers that feel that we need this I won't veto
it (but I am -0.5 on it). And it must configurable without any performance
detriment when disabled (i.e. delete still seeks to the next column). I'd also
vote to default off.
Maybe some of the other committers would like to comment? @Stack, @Ted, @Todd?
> Deletes should not mask Puts that come after it.
> ------------------------------------------------
>
> Key: HBASE-5241
> URL: https://issues.apache.org/jira/browse/HBASE-5241
> Project: HBase
> Issue Type: Improvement
> Reporter: Amitanand Aiyer
> Attachments: HBASE-5241.D1731.1.patch
>
>
> Suppose that we have a delete row, and then followed by the put. The delete
> row
> can mask the put, unless there was a major compaction in between.
> Now that we are flushing the memstoreTS to disk, along with the KVs, we
> should be able
> to differentiate whether or not the Put happened after the Delete and offer
> better
> delete semantics.
> Couldn't find a pre-existing JIRA that already discusses this, so creating
> one.
> Seems related to https://issues.apache.org/jira/browse/HBASE-2406, but is not
> quite the same.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
