Yes, this is quite confusing. Delete.deleteColumn should really be called 
deleteVersion or deleteColumnVersion.
I wonder whether we could make a change like this in the 0.96 "singularity" 
release.

-- Lars



________________________________
 From: Shawn Quinn <squ...@moxiegroup.com>
To: user@hbase.apache.org; lars hofhansl <lhofha...@yahoo.com> 
Sent: Tuesday, March 27, 2012 10:33 AM
Subject: Re: Still Seeing Old Data After a Delete
 

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 <lhofha...@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 <squ...@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
>
>

Reply via email to