hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Marc Spaggiari (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9879) Can't undelete a KeyValue
Date Sat, 02 Nov 2013 19:36:18 GMT

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

Jean-Marc Spaggiari commented on HBASE-9879:

The same way idempotency is broken when someone send puts or increments to a table from into
a mapreduce task. People need to know what they are using. So if they set this parameter to
a table, then they know how it's going to work. Very useful with the timestamp is set by the
client applicatoin and not HBase.

That will also allow to update a specific version of a specific cell. Today it's not possible
to do that. You have to do a delete, flush, compaction and put. With this option, you will
only have to do a put and that will automatically overwrite the previous one. Usefull when
you keep a state as the last version of a cell, but you want to look at the history of the
modifications, and want to update one of them...

> 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=100)
> put(KV, timestamp=200)
> delete(KV, timestamp=200, with MutationProto.DeleteType.DELETE_ONE_VERSION)
> get(KV) => returns value at timestamp=100 (OK)
> put(KV, timestamp=200)
> get(KV) => returns value at timestamp=100 (but not the one at timestamp=200 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
– the first time you run it, it passes, but after that, it keeps failing.  Sorry I don't
have the corresponding 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 releases.
> My hunch is that the tombstone added by the DELETE_ONE_VERSION keeps shadowing the value
even after it's reborn.

This message was sent by Atlassian JIRA

View raw message