[ 
https://issues.apache.org/jira/browse/PHOENIX-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17069200#comment-17069200
 ] 

Hadoop QA commented on PHOENIX-5748:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12998045/PHOENIX-5748-4.x.001.patch
  against 4.x branch at commit d04ba4eb945ba502652888220097ebca44f4a4dd.
  ATTACHMENT ID: 12998045

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:green}+1 tests included{color}.  The patch appears to include 25 new 
or modified tests.

    {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:
    +    private long verifyIndexTable(String tableName, String indexName, 
Connection conn) throws Exception {
+        // Now we rebuild the entire index table and expect that it is still 
good after the full rebuild
+        long actualRowCountAfterCompaction = 
IndexScrutiny.scrutinizeIndex(conn, tableName, indexName);
+                + "(k1 INTEGER NOT NULL, k2 INTEGER NOT NULL, a.v1 INTEGER, 
b.v2 INTEGER, c.v3 INTEGER, d.v4 INTEGER," +
+        conn.createStatement().execute("CREATE INDEX " + indexName + " ON " + 
tableName + "(v1) INCLUDE(v2, v3)");
+                                            + (RAND.nextBoolean() ? null : 
(RAND.nextInt() % nIndexValues)) + ", "
+                + "(k1 INTEGER NOT NULL, k2 INTEGER NOT NULL, a.v1 INTEGER, 
b.v2 INTEGER, c.v3 INTEGER, d.v4 INTEGER," +
+        conn.createStatement().execute("CREATE INDEX " + indexName + " ON " + 
tableName + "(v1) INCLUDE(v2, v3)");
+                                        "UPSERT INTO " + tableName + " (k1, 
k2, b.v2, c.v3, d.v4) VALUES ("
+                                                + (RAND.nextBoolean() ? null : 
RAND.nextInt()) + ", "

    {color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3669//testReport/
Console output: 
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3669//console

This message is automatically generated.

> Simplify index update generation code for consistent global indexes   
> --------------------------------------------------------------------
>
>                 Key: PHOENIX-5748
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5748
>             Project: Phoenix
>          Issue Type: Improvement
>            Reporter: Kadir OZDEMIR
>            Assignee: Kadir OZDEMIR
>            Priority: Major
>             Fix For: 5.1.1, 4.14.4, 4.16.0
>
>         Attachments: PHOENIX-5748-4.x-HBase-1.5.001.patch, 
> PHOENIX-5748-4.x.001.patch, PHOENIX-5748.master.001.patch
>
>
> The implementation of the new global index design by PHOENIX-5156 essentially 
> introduced two coprocessors, IndexRegionObserver and GlobalIndexChecker. 
> IndexRegionObserver is the counterpart of the existing Indexer coprocessor 
> that the previous global indexing feature uses. It implements the indexing 
> write path. GlobalIndexChecker implements the read verification and read 
> repair that happens on the read path. One of the main objectives of the 
> design behind new global indexing was to leverage as much existing indexing 
> code as possible. This objective has been achieved greatly as the entire 
> index table update generation code implemented by various classes (including 
> PhoenixIndexBuilder, CachedLocalTable, NonTxIndexBuilder, IndexUpdateManager, 
>  LocalTableState, ScannerBuilder, IndexMemStore and PhoenixIndexCodec) is 
> leveraged as it is mainly. This objective has served us well to deliver the 
> new indexing feature quickly. The leveraged code is very complex, over 
> engineered, and inefficient, and is not bug free. It is very hard to 
> maintain. It is time to replace the complex set of classes with something 
> drastically simpler and more efficient for the new design.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to