[jira] [Issue Comment Deleted] (OMID-107) Replace HTableInterface with Table

["Yonatan Gottesman (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OMID-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yonatan Gottesman updated OMID-107:
-----------------------------------
    Comment: was deleted

(was: Hi [~jamestaylor], ok my bad there is no loop :).

About the test, I think the writer expected the wrong behaviour of scan with filters (the behaviour we fixed with coprocessors in omid-102).

look at this scan with filter:
{code:java}
Filter f = new SingleColumnValueFilter(famName, colName, CompareFilter.CompareOp.EQUAL, Bytes.toBytes(20));
Scan checkFor20 = new Scan();
checkFor20.setFilter(f);
ResultScanner checkFor20Scanner = txTable.getScanner(tx1, checkFor20);
{code}
The filter f will run before omid filtering, and see the value 18 in row2 even though the value is not in the scanners snapshot, so the filter looking or op.EQUAL 20 won't filter out the row and the row will be returned to omid filtering that will look for the key in our snapshot with the old value 20.

Now tx1 tries to delete row2 and of course will fail because write-write conflict with tx2.

If they had the omid-102 working, and ran the test with the coprocessors, then the filter f would run after omid filtering and see value 20 and emitt the whole row. then the delete  wont take place at all and the snapshot won't fail.

 

I suggest we remove this test and add a log warning every time a user uses a filter in a get/scan op but runs without coprocessors.

 

Does this make sense?)

> Replace HTableInterface with Table
> ----------------------------------
>
>                 Key: OMID-107
>                 URL: https://issues.apache.org/jira/browse/OMID-107
>             Project: Apache Omid
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Priority: Major
>         Attachments: OMID-107.patch
>
>
> In HBase 2.0, the HTableInterface has been replaced with the Table interface. Thus, in Omid, this same replacement should take place. This will mostly be isolated to having TTable implement Table instead of HTableInterface. This will be required to check-in Omid support in Phoenix, since Phoenix 5.x is based on HBase 2.0.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)