[
https://issues.apache.org/jira/browse/HBASE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811955#comment-13811955
]
Jean-Marc Spaggiari commented on HBASE-9879:
--------------------------------------------
BUT.....
The thing is, we now have a way to fix that... But do we want to?
The way will be to use the tags to store a sequence ID for each cell, kind of
timestamp but that user can NOT modify.
That way if someone send a Put, then a Delete then a Put for the EXACT same
cell (row, CF:Q:TS) we can, using the timestamp tag, see which one is supposed
to come first, which one is supposed to come after.
Even better, if someone just to 2 Put with the EXACT same cell again, we can
guarantee that the one pushed in 2nd will be the one which will stay in table
at the end.
We just have to make this as config param per table to not force all the cells
from all the tables to have this system tag.
I have already been asked by few end users if this is possible, and we can not
to that today in 0.94.x but I think that having this is a good idea.
I can give it a try...
> 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)
