[
https://issues.apache.org/jira/browse/PHOENIX-5881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17192964#comment-17192964
]
Josh Elser commented on PHOENIX-5881:
-------------------------------------
{quote}the logic is basically saying "if the timestamp is super-high, that
means Tephra's running this Scan, so don't mess with how HBase treats delete
markers."
{quote}
Thanks Geoffrey. The assumption here is that folks don't write timestamps in
the future for HBase. Generally, I think that sounds appropriate, but it would
be good to write that down somewhere. It looks like the 1.1x is about 5 years
in the future, so probably low risk :)
I can't find the re-kicked job I tried to launch. Reattaching v3 again.
> Port MaxLookbackAge logic to 5.x
> --------------------------------
>
> Key: PHOENIX-5881
> URL: https://issues.apache.org/jira/browse/PHOENIX-5881
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Blocker
> Fix For: 5.1.0
>
> Attachments: PHOENIX-5881.v1.patch, PHOENIX-5881.v2.patch,
> PHOENIX-5881.v3.patch, PHOENIX-5881.v4.patch
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> PHOENIX-5645 wasn't included in the master (5.x) branch because an HBase 2.x
> change prevented the logic from being useful in the case of deletes, since
> HBase 2.x no longer allows us to show deleted cells on an SCN query before
> the point of deletion. Unfortunately, PHOENIX-5645 wound up requiring a lot
> of follow-up work in the IndexTool and IndexScrutinyTool to deal with its
> implications, and because of that, the 4.x and 5.x codebases around indexes
> have diverged a good bit.
> This work item is to get them back in sync, even though the behavior in the
> face of deletes will be somewhat different, and so most likely some tests
> will have to be changed or Ignored.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
