Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <1332868768.80321.YahooMailNeo@web121702.mail.ne1.yahoo.com>
References: 
 <CAC6UP6Ku894aiJPHpUxPE+Nu101QkO_YdHwqpg3y4XinhAPLug@mail.gmail.com>
	<1332868768.80321.YahooMailNeo@web121702.mail.ne1.yahoo.com>
Date: Tue, 27 Mar 2012 13:33:54 -0400
Message-ID: 
 <CAC6UP6+vkRaF7CovXV-ScCHOynPJvniN9wAxxTA56deiSrfSMA@mail.gmail.com>
Subject: Re: Still Seeing Old Data After a Delete
From: Shawn Quinn <squinn@moxiegroup.com>
To: user@hbase.apache.org, lars hofhansl <lhofhansl@yahoo.com>
Content-Type: multipart/alternative; boundary=e89a8f64715b1ca4c904bc3ce53f

--e89a8f64715b1ca4c904bc3ce53f
Content-Type: text/plain; charset=ISO-8859-1

Hi Lars,

Thanks for the quick reply!  In this case we we're doing a column delete
like so:

            Delete delete = new Delete(rowKey);
            delete.deleteColumn(Bytes.toBytes("thing"),
Bytes.toBytes(value));
            table.delete(delete);

However, your response caused me to notice the "Delete.deleteColumns()"
method in the JavaDoc instead of simply "Delete.deleteColumn()".  Calling
the "deleteColumns" instead of "deleteColumn" fixes the problem we were
seeing.  That wasn't immediately obvious to me after reading the book, but
after reading the JavaDoc I now understand the distinction between the two
methods.

I may be the only one who missed that at first, but in case others have a
similar confusion it might be worth a comment in the book that
"deleteColumn()" is really only for deleting a single version and
"deleteColumns()" is for deleting all versions.  E.g. the second type noted
in the book currently is listed as "Delete column: for all versions of a
column".  But, from the API perspective that's really the "deleteColumns()"
method.  (Whereas, my incorrect intuition when just looking at the API was
that the "deleteColumns()" method would likely be for deleting multiple
different columns.)

Thanks again for the quick follow up,

     -Shawn

On Tue, Mar 27, 2012 at 1:19 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:

> Hey Shawn,
>
> how exactly did you delete the column?
> There are three types of delete markers: family, column, version.
> Your observation would be consistent with having used a version delete
> marker, which just marks are a specific version (the latest by default) for
> delete.
>
> Check out the HBase Reference Guide:
> http://hbase.apache.org/book.html#version.delete
>
> Also, if you don't mind the plug see a more detailed discussion here:
> http://hadoop-hbase.blogspot.com/2011/12/deletion-in-hbase.html
>
> -- Lars
>
>
> ----- Original Message -----
> From: Shawn Quinn <squinn@moxiegroup.com>
> To: user@hbase.apache.org
> Cc:
> Sent: Tuesday, March 27, 2012 10:01 AM
> Subject: Still Seeing Old Data After a Delete
>
> Hello,
>
> In a couple of situations we were noticing some odd problems with old data
> appearing in the application, and I finally found a reproducible scenario.
> Here's what we're seeing in one basic case:
>
> 1. Using a scan in hbase shell one of our column cells (both the column
> name and value are simple long's) looks like so:
>
> column=thing:\x00\x00\x00\x00\x00\x00\x00\x02, timestamp=1332795701976,
> value=\x00\x00\x00\x00\x00\x00\x00s
>
> 2. If we then use a "Put" to update that cell to a new value it looks as
> we'd expect like so:
>
> column=thing:\x00\x00\x00\x00\x00\x00\x00\x02, timestamp=1332866682295,
> value=\x00\x00\x00\x00\x00\x00\x00u
>
> 3. If we then use a "Delete" to remove that column, instead of the column
> no longer being included in the scan we instead see the following again:
>
> column=thing:\x00\x00\x00\x00\x00\x00\x00\x02, timestamp=1332795701976,
> value=\x00\x00\x00\x00\x00\x00\x00s
>
> So, for some reason, at least in this case, the tombstone/delete marker
> doesn't appear to be preventing new scans from no longer seeing the old
> data.
>
> Note that this is a small development cluster of HBase (version:
> hbase-0.90.4-cdh3u2) which contains one master and three region servers,
> and I have confirmed that the clocks are synchronized properly between the
> four machines.  Also note that we're using the Java client API to run the
> Put/Delete commands noted above.
>
> Any ideas on how old data could still appear in a Get/Scan like this, and
> if there are any workarounds we could try?  I saw HBASE-4536, but after
> reading that thread it didn't seem pertinent to this more basic scenario.
>
> Thanks in advance for any pointers!
>
>       -Shawn
>
>

--e89a8f64715b1ca4c904bc3ce53f--