[
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)
