hbase-issues mailing list archives

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

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

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

To be precise, the idea was to optionally let a Table or ColumnFamily declare whether or not
it would allow a client to set timestamps.


> 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