Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 6 Jan 2015 16:20:36 +0000 (UTC)
From: "Cosmin Lehene (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12538467.1326679776000.20291.1420561236069@Atlassian.JIRA>
In-Reply-To: <JIRA.12538467.1326679776000@Atlassian.JIRA>
References: <JIRA.12538467.1326679776000@Atlassian.JIRA>
 <JIRA.12538467.1326679776799@arcas>
Subject: [jira] [Commented] (HBASE-5205) Delete handles deleteFamily
 incorrectly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Cosmin Lehene commented on HBASE-5205:
--------------------------------------

[~lhofhansl] did this fall through the cracks because it didn't have a fixVersion?

> Delete handles deleteFamily incorrectly
> ---------------------------------------
>
>                 Key: HBASE-5205
>                 URL: https://issues.apache.org/jira/browse/HBASE-5205
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>            Reporter: Lars Hofhansl
>            Priority: Minor
>         Attachments: 5205.txt
>
>
> Delete.deleteFamily clears all other markers for the same family.
> That is not correct as some of these other markers might be for a later time.
> That logic should be removed.
> If (really) needed this can be slightly optimized by keeping track of the max TS so far for each family.
> If both the TS-so-far and the TS of a new deleteFamily request is < LATEST_TIMESTAMP and the TS-so-far is < deleteFamily marker, or if both the TS-so-far and the new TS equal LATEST_TIMESTAMP, then the previous delete markerz for that family could be removed.
> I think that might be overkill, as most deletes issued from clients are for LATEST_TIMESTAMP (which the server translates to the current time).
> I'll have a (one-line) patch soon. Unless folks insist on the optimization I mentioned above.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)