Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 2 Nov 2013 19:52:18 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12677177.1383350171038.11628.1383421938491@arcas>
In-Reply-To: <JIRA.12677177.1383350171038@arcas>
References: <JIRA.12677177.1383350171038@arcas>
Subject: [jira] [Commented] (HBASE-9879) Can't undelete a KeyValue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HBASE-9879?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1381=
2129#comment-13812129 ]=20

Lars Hofhansl commented on HBASE-9879:
--------------------------------------

In fact with HTable you have both option: (1) target the last version for d=
elete (2) mark a specific version for delete.
In either case a version delete marker will hide a put of the same ts.

> Can't undelete a KeyValue
> -------------------------
>
>                 Key: HBASE-9879
>                 URL: https://issues.apache.org/jira/browse/HBASE-9879
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.96.0
>            Reporter: Benoit Sigoure
>
> Test scenario:
> put(KV, timestamp=3D100)
> put(KV, timestamp=3D200)
> delete(KV, timestamp=3D200, with MutationProto.DeleteType.DELETE_ONE_VERS=
ION)
> get(KV) =3D> returns value at timestamp=3D100 (OK)
> put(KV, timestamp=3D200)
> get(KV) =3D> returns value at timestamp=3D100 (but not the one at timesta=
mp=3D200 that was "reborn" by the previous put)
> Is that normal?
> I ran into this bug while running the integration tests at https://github=
.com/OpenTSDB/asynchbase/pull/60 =E2=80=93 the first time you run it, it pa=
sses, but after that, it keeps failing.  Sorry I don't have the correspondi=
ng HTable-based code but that should be fairly easy to write.
> I only tested this with 0.96.0, dunno yet how this behaved in prior relea=
ses.
> My hunch is that the tombstone added by the DELETE_ONE_VERSION keeps shad=
owing the value even after it's reborn.


--
This message was sent by Atlassian JIRA
(v6.1#6144)