[
https://issues.apache.org/jira/browse/HBASE-18638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136661#comment-16136661
]
Chia-Ping Tsai commented on HBASE-18638:
----------------------------------------
bq. If the user wants to keep the old cell once the new one is TTL expired, he
should have configured CF versions>1
Thanks for the clear explanation.
bq. Based on whether flush happened or not or which HFiles having this 2 cells
and whether compaction across those files happened, the result can vary. This
is a known issue only.
I'm late to the party. The
[doc|http://hbase.apache.org/book.html#major.compactions.change.query.results]
speaks about the "result change", but only Delete is mentioned.
bq. How we handle the versions.
I have finished a draft. Having run more tests, I will be back.
> There are version-related dirty data caused by delete/ttl
> ---------------------------------------------------------
>
> Key: HBASE-18638
> URL: https://issues.apache.org/jira/browse/HBASE-18638
> Project: HBase
> Issue Type: Bug
> Affects Versions: 1.3.1, 1.2.6, 2.0.0-alpha-1
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Critical
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
> Attachments: HBASE-18638-ut.patch, HBASE-18638-ut.patch
>
>
> |put_0(t0)|
> |put_1(t1)| <-- the latest cell
> If we call get, the put_1 will return. That is good.
> If we call get after a delete, the put_0 will return. That is weird. The
> put_0 is old data, and it should be dropped in flush. For client, put_0
> should not exist after the put_1 happen.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
