[
https://issues.apache.org/jira/browse/HBASE-8721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13690464#comment-13690464
]
Andrew Purtell commented on HBASE-8721:
---------------------------------------
[[email protected]] Did that once before. Looking at votes, we have: Lars
(-1), Sergey (-0), me (-0). If we tease this apart, we get HBASE-8770, where
looks like we have a way forward on addressing this part:
Feng:
{quote}
User can always read the put by 4>. It's more natural and intuitive:
1> put a kv (timestamp = T0), and flush;
2> delete that kv using a DeleteColumn type kv with timestamp T0 (or any
timestamp >= T0), and flush;
3> a major compact occurs [or not];
4> put that kv again (timestamp = T0);
5> read that kv;
===>
a) if a major compact occurs at step 3>, then step 5> will get the put written
at step 4>
b) if no major compact occurs at step 3>, then step 5> get nothing
{quote}
But for the other part of the argument, expressed by Hangjun:
{quote}
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. [...] Conceptually decoupling the timestamp and the
"happened-before" relationship inside hbase should give users more flexibility
to decide how to use it.
{quote}
the discussion consensus reads to me as: users submitting their own timestamps
have to actually produce happened-before relationships by issuing ops with
_different_ timestamps, and not rely on HBase to also remember op arrival order
internally for breaking ties when the ops have the same logical "time".
We have a standing firm -1 on changing that part. What do you think? Would you
+1 it? Under what circumstances would Lars change his -1 to a +1? I don't see
that but don't presume to speak for him.
> 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
