[
https://issues.apache.org/jira/browse/PHOENIX-5748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046099#comment-17046099
]
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/12994720/PHOENIX-5748-4.x-HBase-1.5.001.patch
against 4.x-HBase-1.5 branch at commit
00aec741b4654db11d7bb3dadd46236ccc7cde10.
ATTACHMENT ID: 12994720
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 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
+ + "(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)) + ", "
+ @Ignore ("It is not possible to assign the same timestamp two separately
committed mutations in the current model\n" +
+ " except when the server time goes backward. In that case, the
behavior is not deterministic")
+ // Since all the rows are in the index table, running the index
tool with the "-v BEFORE" option should not
+ populateTable(dataTableName); // with two rows ('a', 'ab', 'abc',
'abcd') and ('b', 'bc', 'bcd', 'bcde')
+ populateTable(dataTableName); // with two rows ('a', 'ab', 'abc',
'abcd') and ('b', 'bc', 'bcd', 'bcde')
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3499//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/3499//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
>
>
> 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)
