[
https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16728419#comment-16728419
]
Wellington Chevreuil commented on HBASE-21596:
----------------------------------------------
Actually previous approach wouldn't work when having to proper track the number
of versions. I guess we need to add a delete mark for a given cell whenever it
exceeds the max version limit, otherwise, extra versions still in memstore can
still be returned by scanners depending on how many deletes had occurred for
newer cells still in the memstore.
On Delete mutation execution, we do look (run a Get) for the cell version on
*HRegion.prepareDeleteTimestamps* method, so that we can update the Delete cell
type TS with the version wanted. One option is to also check for extra versions
here, and add Delete cells for any extra version. Am attaching a temporary
initial patch with initial changes. Major changes are under
*HRegion.updateDeleteLatestVersionTimestamp*, where I'm actually scanning over
all existing versions of the given cell, and adding delete cells for cells
exceeding max version. This required a change on StoreScanner, to allow it to
define raw scans when CF is defined. Maybe we could make this available for
internal scans only, not sure what is the motivation on not allowing CF
definitions for raw scans.
> 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
>
> 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)
