[
https://issues.apache.org/jira/browse/HBASE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688845#comment-13688845
]
Hangjun Ye commented on HBASE-8721:
-----------------------------------
I got Sergey and Lars' point...
My personal point is tiemstamp is a logical version, which is often the same as
the "happened-before" relationship inside hbase, but not necessarily have to
be. User could assign any semantics to it since it has been exposed and user
could set it explicitly.
For example, Percolator/Megastore/Spanner used it to store transaction id.
A web search repository might use it to store the time when the page was
fetched, instead of the time when the page was inserted into the repository
(they are not necessarily the same one). Here the timestamp is also a kind of
"happened-before" relationship, but it's defined "outside" the hbase, not
"inside".
Conceptually decoupling the timestamp and the "happened-before" relationship
inside hbase should give users more flexibility to decide how to use it.
Lars said changing the semantics would break something, do you mean some users
rely on the KEEP_DELETED_CELLS and want the feature "Delete can mask puts that
happen after the delete"?
If so, how about we introduce a new config to control whether "Delete can mask
puts that happen after the delete" or not?
The current behavior is problematic for our clients and they really don't want
the delete masks future puts. Possibly some others have similar issue and we
could let users choose what behavior they want.
> Deletes can mask puts that happen after the delete
> --------------------------------------------------
>
> Key: HBASE-8721
> URL: https://issues.apache.org/jira/browse/HBASE-8721
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Feng Honghua
> Attachments: HBASE-8721-0.94-V0.patch
>
>
> this fix aims for bug mentioned in http://hbase.apache.org/book.html 5.8.2.1:
> "Deletes mask puts, even puts that happened after the delete was entered.
> Remember that a delete writes a tombstone, which only disappears after then
> next major compaction has run. Suppose you do a delete of everything <= T.
> After this you do a new put with a timestamp <= T. This put, even if it
> happened after the delete, will be masked by the delete tombstone. Performing
> the put will not fail, but when you do a get you will notice the put did have
> no effect. It will start working again after the major compaction has run.
> These issues should not be a problem if you use always-increasing versions
> for new puts to a row. But they can occur even if you do not care about time:
> just do delete and put immediately after each other, and there is some chance
> they happen within the same millisecond."
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
