[ 
https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16759736#comment-16759736
 ] 

Wellington Chevreuil commented on HBASE-21596:
----------------------------------------------

I tried this originally, but actually found some problems while testing:

1) Say a CF with VERSIONS=>3 and a given cell that has 3 versions, all in 
memstore, T1, T2, T3, then a delete is triggered for T2 (let's call this marker 
DT2), scan would show now only T3, filtering T2 (because it has DT2), and T1 
(because T3, T2 and DT2 already reaches 3 versions). This could be sorted by 
skipping counting T2 in this case, but then found another problem below:

 

2) Say a CF with VERSIONS=>3 and a given cell that has 4 versions, all in 
memstore: T1, T2, T3, T4, then a delete is triggered for T2. So this cell would 
now havw: T1, T2, DT2, T3, T4. Scan would correctly be showing T4 and T3 only. 
However, if memstore flush occurs, it will filter out delete marker and it's 
related cell, so in this case, T4, T3 and T1 would be written, and a new scan 
would now show T4, T3 and T1, bringing back a version that was supposed to be 
gone already.

Given those, I thought safer was to always put a delete marker for the extra 
cells extrapolating the max number of versions.

> HBase Shell "delete" command can cause older versions to be shown even if 
> VERSIONS is configured as 1
> -----------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-21596
>                 URL: https://issues.apache.org/jira/browse/HBASE-21596
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Wellington Chevreuil
>            Assignee: Wellington Chevreuil
>            Priority: Minor
>         Attachments: HBASE-21596-master.001.patch, 
> HBASE-21596-master.002.patch, HBASE-21596-master.003.patch, initial-patch.txt
>
>
> HBase Shell delete command is supposed to operate over an specific TS. If no 
> TS is informed, it will assume the latest TS for the cell and put delete 
> marker for it. 
> However, for a CF with VERSIONS => 1, if multiple puts were performed for 
> same cell, there may be multiple cell versions on the memstore, so delete 
> would only be "delete marking" one of those, and causing the most recent no 
> marked one to be shown on gets/scans, which then contradicts the CF "VERSIONS 
> => 1" configuration.
> This issue is not seen with deleteall command or using Delete operation from 
> Java API.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to