[
https://issues.apache.org/jira/browse/PHOENIX-5559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973073#comment-16973073
]
Hadoop QA commented on PHOENIX-5559:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12985675/5559-4.x-HBase-1.5-v5.txt
against 4.x-HBase-1.5 branch at commit
f8cfa6b8b9f63ab080cdafa486bb4aabf043b1f8.
ATTACHMENT ID: 12985675
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ "CLIENT PARALLEL 1-WAY RANGE SCAN OVER " + tableName +
" [" + (1L + expectedIndexIdOffset) + ",'" + tenantId + "','" + valuePrefix +
"v2-1']\n"
+ "CLIENT PARALLEL 3-WAY RANGE SCAN OVER " + tableName + "
[" + (1L + expectedIndexIdOffset) + ",'" + tenantId + "','" + valuePrefix +
"v2-1']\n"
+ "CLIENT PARALLEL 1-WAY RANGE SCAN OVER _IDX_" + tableName
+ " [" + (Short.MIN_VALUE + expectedIndexIdOffset) + ",'" + tenantId + "','" +
valuePrefix + "v2-1']\n"
+ "CLIENT PARALLEL 3-WAY RANGE SCAN OVER _IDX_" + tableName
+ " [0," + (Short.MIN_VALUE + expectedIndexIdOffset) + ",'" + tenantId + "','"
+ valuePrefix +
+ "v2-1'] - ["+(saltBuckets.intValue()-1)+"," +
(Short.MIN_VALUE + expectedIndexIdOffset) + ",'" + tenantId + "','" +
valuePrefix + "v2-1']\n"
+ ? "CLIENT PARALLEL 1-WAY RANGE SCAN OVER " +
viewIndexPhysicalName +" [" + Short.MIN_VALUE + ",51]"
+ : "CLIENT PARALLEL " + saltBuckets + "-WAY RANGE
SCAN OVER " + viewIndexPhysicalName + " [0," + Short.MIN_VALUE + ",51] -
["+(saltBuckets.intValue()-1)+"," + Short.MIN_VALUE + ",51]\nCLIENT MERGE SORT",
+ ? "CLIENT PARALLEL 1-WAY RANGE SCAN OVER " +
viewIndexPhysicalName +" [" + (Short.MIN_VALUE+1) + ",'foo']\n"
+ : "CLIENT PARALLEL " + saltBuckets + "-WAY RANGE
SCAN OVER " + viewIndexPhysicalName + " [0," + (Short.MIN_VALUE+1) + ",'foo'] -
["+(saltBuckets.intValue()-1)+"," + (Short.MIN_VALUE+1) + ",'foo']\n"
+ + " [" + Long.toString(Short.MIN_VALUE + indexIdOffset) +
",'" + tenantId + "','f']\n" + " SERVER FILTER BY FIRST KEY ONLY",
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3119//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3119//console
This message is automatically generated.
> Fix remaining issues with Long viewIndexIds
> -------------------------------------------
>
> Key: PHOENIX-5559
> URL: https://issues.apache.org/jira/browse/PHOENIX-5559
> Project: Phoenix
> Issue Type: Improvement
> Affects Versions: 4.15.0, 5.1.0
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Priority: Blocker
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5559-4.x-HBase-1.5-v2.txt, 5559-4.x-HBase-1.5-v3.txt,
> 5559-4.x-HBase-1.5-v5.txt, 5559-4.x-HBase-1.5.txt, 5559-4.x-HBase-1.5.txt,
> 5559-test.txt
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> 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:
> {code:java}
> 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{code}
> 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.
> [~gjacoby] [~rajeshbabu]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
