[
https://issues.apache.org/jira/browse/HBASE-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evert Arckens updated HBASE-1485:
---------------------------------
Attachment: TestCellUpdates.java
We've tried the patch posted at https://review.cloudera.org/r/780/ here at
Outerthought.
The attached file is a unit test showing that the patch works at first sight.
However, performing updates on existing timestamps, in combination with
triggering major compactions things don't work as expected.
I've used negative-assertions in order to make the tests succeed, and added a
comment where we would expect the result to be otherwise.
I've also added a test with the example where a row is deleted and then an
update on an older timestamp afterwards remains hidden by the delete.
> Wrong or indeterminate behavior when there are duplicate versions of a column
> -----------------------------------------------------------------------------
>
> Key: HBASE-1485
> URL: https://issues.apache.org/jira/browse/HBASE-1485
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.20.0
> Reporter: Jonathan Gray
> Assignee: Pranav Khaitan
> Fix For: 0.90.0
>
> Attachments: TestCellUpdates.java
>
>
> As of now, both gets and scanners will end up returning all duplicate
> versions of a column. The ordering of them is indeterminate.
> We need to decide what the desired/expected behavior should be and make it
> happen.
> Note: It's nearly impossible for this to work with Gets as they are now
> implemented in 1304 so this is really a Scanner issue. To implement this
> correctly with Gets, we would have to undo basically all the optimizations
> that Gets do and making them far slower than a Scanner.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
