[ https://issues.apache.org/jira/browse/PHOENIX-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541179#comment-16541179
]
Hadoop QA commented on PHOENIX-3534:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12931252/PHOENIX-3534-v3.patch
against master branch at commit aee568beb02cdf983bb10889902c338ea016e6c9.
ATTACHMENT ID: 12931252
{color:green}+1 @author{color}. The patch does not contain any @author tags.
{color:green}+1 tests included{color}. The patch appears to include 29 new or modified
tests.
{color:green}+1 javac{color}. The applied patch does not increase the total number of
javac compiler warnings.
{color:red}-1 release audit{color}. The applied patch generated 3 release audit warnings
(more than the master's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines longer than
100:
+ conn.createStatement().execute("CREATE LOCAL INDEX " + generateUniqueName()
+ " ON " + tableName + "(KV1)");
+ assertEquals(4, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k2"), fullView2IndexName));
+ assertEquals(5, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k3"), fullView2IndexName));
+ assertEquals(4, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k2"), fullView3IndexName));
+ assertEquals(5, getIndexOfPkColumn(phxConn, IndexUtil.getIndexColumnName(null,
"k3"), fullView3IndexName));
+ String view1DDL = "CREATE VIEW " + view1 + " ( VIEW_COL1 DECIMAL(10,2), VIEW_COL2
CHAR(256)) AS SELECT * FROM " + baseTable;
+ String divergedViewDDL = "CREATE VIEW " + divergedView + " ( VIEW_COL1 DECIMAL(10,2),
VIEW_COL2 CHAR(256)) AS SELECT * FROM " + baseTable;
+ String indexDDL = "CREATE INDEX " + divergedViewIndex + " ON " + divergedView
+ " (V1) include (V3)";
+ assertTableDefinition(tenant1Conn, view1, PTableType.VIEW, baseTable, 0, 7, 5,
"PK1", "V1", "V2", "V3", "KV", "PK2", "VIEW_COL1", "VIEW_COL2");
+ assertTableDefinition(tenant2Conn, divergedView, PTableType.VIEW, baseTable,
1, 6, DIVERGED_VIEW_BASE_COLUMN_COUNT, "PK1", "V1", "V3", "PK2", "VIEW_COL1", "VIEW_COL2");
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexIT
{color:red}-1 core zombie tests{color}. There are 4 zombie test(s): at org.apache.phoenix.end2end.DeleteIT.testPointDeleteRowFromTableWithImmutableIndex(DeleteIT.java:403)
at org.apache.phoenix.end2end.DeleteIT.testPointDeleteRowFromTableWithImmutableIndex(DeleteIT.java:376)
at org.apache.phoenix.end2end.DefaultColumnValueIT.testDefaultColumnValue(DefaultColumnValueIT.java:66)
Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1926//testReport/
Release audit warnings: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1926//artifact/patchprocess/patchReleaseAuditWarnings.txt
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1926//console
This message is automatically generated.
> Support multi region SYSTEM.CATALOG table
> -----------------------------------------
>
> Key: PHOENIX-3534
> URL: https://issues.apache.org/jira/browse/PHOENIX-3534
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Priority: Major
> Fix For: 5.0.0, 4.15.0
>
> Attachments: PHOENIX-3534-v2.patch, PHOENIX-3534-v3.patch, PHOENIX-3534.patch
>
>
> Currently Phoenix requires that the SYSTEM.CATALOG table is single region based on the
server-side row locks being held for operations that impact a table and all of it's views.
For example, adding/removing a column from a base table pushes this change to all views.
> As an alternative to making the SYSTEM.CATALOG transactional (PHOENIX-2431), when a new
table is created we can do a lazy cleanup of any rows that may be left over from a failed
DDL call (kudos to [~lhofhansl] for coming up with this idea). To implement this efficiently,
we'd need to also do PHOENIX-2051 so that we can efficiently find derived views.
> The implementation would rely on an optimistic concurrency model based on checking our
sequence numbers for each table/view before/after updating. Each table/view row would be individually
locked for their change (metadata for a view or table cannot span regions due to our split
policy), with the sequence number being incremented under lock and then returned to the client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
|