[
https://issues.apache.org/jira/browse/HBASE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13684091#comment-13684091
]
Lars Hofhansl commented on HBASE-8721:
--------------------------------------
The timestamp is part of the schema. A Put is masked by a newer delete. If we
did not have that as-of-time queries would be broken and we would break the
idempotent nature of operations in HBase.
We have two "happened-before" relationships:
# the one defined by the timestamps
# the one corresponding to the actual time when an operation hits a region
server
The two only represent different relationship if client set timestamp do not
represent the actual chronological order of things.
HBase allows you to set the timestamps to influence the logical order in which
things (are declared to have) happened.
If you do not want strange behavior do not date Deletes into the future and
Puts into the past. Period.
-1 from me, unless there's more reasoning as why we need to break these nice
properties of HBase.
I'd much rather introduce a config option for a Table or ColumnFamily that
simply disallows client set timestamps. That way all these problems go away in
nice fashion.
> 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
