[
https://issues.apache.org/jira/browse/HBASE-15487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203756#comment-15203756
]
Anoop Sam John commented on HBASE-15487:
----------------------------------------
bq.builder.setDeleteType(DeleteType.VERSION);
Oh I noticed it now. Why delete type is version when u actually wanted to
delete one row:cf:qual value fully? Version type to be used when u want to
delete one particular version of a cell.
Yes as per the thinking it is correct to put even version also.. Because u have
1 as max versions for the table. So when new data was put ideally it has to
shadow the old one. So even if latest version only deleted, it should work
correctly.
But this is a know issue in HBase.. When version is 1, the actual removal of
old version data will happen during a compaction. So before u apply this bulk
delete op, if a compaction happened, you would have been seeing the correct
result you wanted..
For ur case I think it can be easily fixed by removing this DeleteType.VERSION
type set.
> Deletions done via BulkDeleteEndpoint make past data re-appear
> --------------------------------------------------------------
>
> Key: HBASE-15487
> URL: https://issues.apache.org/jira/browse/HBASE-15487
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.0.3
> Reporter: Mathias Herberts
> Attachments: HBaseTest.java, HBaseTest.java
>
>
> The Warp10 (www.warp10.io) time series database uses HBase as its underlying
> data store. The deletion of ranges of cells is performed using the
> BulkDeleteEndpoint.
> In the following scenario the deletion does not appear to be working properly:
> The table 't' is created with a single version using:
> create 't', {NAME => 'v', DATA_BLOCK_ENCODING => 'FAST_DIFF', BLOOMFILTER =>
> 'NONE', REPLICATION_SCOPE => '0', VERSIONS=> '1', MIN_VERSIONS => '0', TTL =>
> '2147483647', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY
> =>'false', BLOCKCACHE => 'true'}
> We write a cell at row '0x00', colfam 'v', colq '', value 0x0
> We write the same cell again with value 0x1
> A scan will return a single value 0x1
> We then perform a delete using the BulkDeleteEndpoint and a Scan with a
> DeleteType of 'VERSION'
> The reported number of deleted versions is 1 (which is coherent given the
> table was created with MAX_VERSIONS=1)
> The same scan as the one performed before the delete returns a single value
> 0x0.
> This seems to happen when all operations are performed against the memstore.
> A regular delete will remove the cell and a later scan won't show it.
> I'll attach a test which demonstrates the problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
