Description
Update: Since I uncovered more problems here, I changed the title.
This fixes the following three issues:
1. PHOENIX-5550, local index is not correctly built when data existed in the data table.
2. Index ids are correctly generated on the client, so that index updates for different indexes are written into the same index.
3. Stale boundary cache is not correctly detected in some cases (namely when the scan already was in the second daughter region and that daugthter region is the last region.)
All of these happen when short view index ids are used (which is the default). The included test covers all three scenarios.
Was:
phoenix: CREATE TABLE test (pk INTEGER PRIMARY KEY, v1 INTEGER, v2 integer);
No rows affected (1.389 seconds)
phoenix: create local index l1 on test(v1);
1 row affected (11.343 seconds)
phoenix: create local index l2 on test(v1);
1 row affected (5.107 seconds)
phoenix: UPSERT INTO test VALUES(2,2,2);
1 row affected (0.037 seconds)
hbase: scan 'TEST'
ROW COLUMN+CELL
\x00\x00\xC1\x03\x00\x80\x00\x00\x02 column=L#0:\x00\x00\x00\x00, timestamp=1572842063925, value=x
\x80\x00\x00\x02 column=0:\x00\x00\x00\x00, timestamp=1572842063925, value=x
\x80\x00\x00\x02 column=0:\x80\x0B, timestamp=1572842063925, value=\x80\x00\x00\x02
\x80\x00\x00\x02 column=0:\x80\x0C, timestamp=1572842063925, value=\x80\x00\x00\x02
2 row(s) in 0.0190 seconds
There should be two index rows.
And in fact there are with phoenix.index.longViewIndex.enabled set to true, there are correctly two different index entries for both of the local indexes.
Attachments
Attachments
Issue Links
- duplicates
-
PHOENIX-5550 Scan after local index creation on table having data giving wrong results when long view index id disabled
-
- Resolved
-
- links to
