hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HBASE-9879) Can't undelete a KeyValue
Date Sat, 02 Nov 2013 21:13:20 GMT

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

Andrew Purtell edited comment on HBASE-9879 at 11/2/13 9:12 PM:
----------------------------------------------------------------

bq. Very useful with the timestamp is set by the client applicatoin and not HBase.

There was support in the recent PMC meeting for deprecating client set timestamps. Existing
tables would grandfather a setting that allows user set timestamps but new tables would not
allow them. Allowing clients to (ab)use cell timestamps leads to several problems not just
this known issue. 

Edit: Did not change the jira type.


was (Author: apurtell):
bq. Very useful with the timestamp is set by the client applicatoin and not HBase.

There was support in the recent PMC meeting for deprecating client set timestamps. Existing
tables would grandfather a setting that allows user set timestamps but new tables would not
allow them. Allowing clients to (ab)use cell timestamps leads to several problems not just
this known issue. And it's not a bug strictly speaking so I have changed the JIRA issue type
accordingly.

> 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
(v6.1#6144)

Mime
View raw message