Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 21 Jun 2013 16:46:23 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12651914.1370771660293.155930.1371833183958@arcas>
In-Reply-To: <JIRA.12651914.1370771660293@arcas>
References: <JIRA.12651914.1370771660293@arcas>
Subject: [jira] [Commented] (HBASE-8721) Deletes can mask puts that happen
 after the delete
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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:
---------------------------------------

[~saint.ack@gmail.com] 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