[
https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16743407#comment-16743407
]
Wellington Chevreuil commented on HBASE-21596:
----------------------------------------------
{quote}This would seem to argue that we should not allow explicit delete of a
single Cell version – we should always delete all behind the tombstone?
{quote}
Good point, I guess that would then require an API change, since
*Delete.addColumn(family,qualifier)/Delete.addColumn(family,qualifier,timestamp)*
wouldn't make sense. Ain't sure how important this feature is, since it seems
broken for a while, so maybe minimal impact to have this API change.
{quote}A point delete could always revive the Cell that was just outside the
version window – at least until the major compaction runs?
{quote}
So this latest submitted patch fixes that by also adding delete markers to any
existing extra versions once a delete for an specific TS is ran. The way shell
delete was behaving prior to HBASE-18142 was that it was always deleting all
versions (calling *Delete.addColumns*, instead of *Delete.addColumn* with the
latest TS).
> 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)
