[
https://issues.apache.org/jira/browse/HBASE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689043#comment-13689043
]
Lars Hofhansl commented on HBASE-8721:
--------------------------------------
If your clients use the timestamp not as a timestamp, can they add whatever
their values are to the rowkey?
bq. do you mean some users rely on the KEEP_DELETED_CELLS and want the feature
"Delete can mask puts that happen after the delete"?
Exactly. When KEEP_DELETED_CELLS is enabled you can do true time range queries
in HBase. For example you get the exact state of your data as of last week, or
an hour ago, etc; even when data was deleted via delete markers.
I think adding a global or maybe column family config option to change this
behavior is fine, as long as the code does not get too convoluted. In that case
we need to make sure then that all other HBase features such as replication,
WAL replay, as-of-time queries, bulk loading HFiles, etc still work as
expected. Also need to check that the HFile metadata is still correct as the
timerange of the included KVs is used to exclude HFile from scans in some
situations (if if you put a Delete marker at MAX_LONG this HFile would not be
excluded for queries on new data, unless we add some other special logic).
Even in that case I'd still be -0 on this (but I would no longer veto it with a
-1) - this looks like a very app specific use case to me.
You would need to find one or two committers who are ready to +1 this feature
and patch to get it committed.
> 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
