[
https://issues.apache.org/jira/browse/PHOENIX-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16765647#comment-16765647
]
Hadoop QA commented on PHOENIX-5132:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12958325/PHOENIX-5132-4.x-HBase-1.4.patch
against 4.x-HBase-1.4 branch at commit
0d44f7625a7958d58fa596bdd0da67ff501da84c.
ATTACHMENT ID: 12958325
{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:red}-1 release audit{color}. The applied patch generated 1 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:
+ private void createView(Connection conn, String schemaName, String
viewName, String baseTableName) throws SQLException {
+ conn.createStatement().execute("CREATE VIEW " + fullViewName + " AS
SELECT * FROM " + fullTableName);
+ private void createViewIndex(Connection conn, String schemaName, String
indexName, String viewName,
+ conn.createStatement().execute("CREATE INDEX " + indexName + " ON " +
fullViewName + "(" + indexColumn + ")");
+ props.setProperty(QueryServices.IS_NAMESPACE_MAPPING_ENABLED,
Boolean.toString(isNamespaceMapped));
+ PTable globalViewIndexTable = PhoenixRuntime.getTable(globalConn,
SCHEMA1 + "." + globalViewIndexName);
+ PTable tenantViewIndexTable = PhoenixRuntime.getTable(tenantConn,
SCHEMA1 + "." + tenantViewIndexName);
+ Assert.assertNotEquals(globalViewIndexTable.getViewIndexId(),
tenantViewIndexTable.getViewIndexId());
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.trace.PhoenixTracingEndToEndIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.PartialIndexRebuilderIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TenantSpecificViewIndexSaltedIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TenantSpecificViewIndexIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/2328//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/2328//artifact/patchprocess/patchReleaseAuditWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/2328//console
This message is automatically generated.
> View indexes with different owners but of the same base table can be assigned
> same ViewIndexId
> ----------------------------------------------------------------------------------------------
>
> Key: PHOENIX-5132
> URL: https://issues.apache.org/jira/browse/PHOENIX-5132
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.0.0, 4.14.1
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
> Priority: Critical
> Attachments: PHOENIX-5132-4.x-HBase-1.4.patch,
> PHOENIX-5132-repro.patch
>
>
> All indexes on views for a particular base table are stored in the same
> physical HBase table. Phoenix distinguishes them by prepending each row key
> with an encoded short or long integer called a ViewIndexId.
> The ViewIndexId is generated by using a sequence to guarantee that each view
> index id is unique. Unfortunately, the sequence used follows a convention of
> [SaltByte, Tenant, Schema, BaseTable] for its key, which means that there's a
> separate sequence for each tenant that owns an index in the view index table.
> (See MetaDataUtil.getViewIndexSequenceKey) Since all the sequences start at
> the same value, collisions are not only possible but likely.
> I've written a test that confirms the ViewIndexId collision. This means it's
> very likely that query results using one view index could mistakenly include
> rows from another index, but I haven't confirmed this.
> All view indexes for a base table, regardless of whether globally or
> tenant-owned, should use the same sequence.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
