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

Hadoop QA commented on PHOENIX-4229:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12891326/PHOENIX-4229.patch
  against master branch at commit ebfff4e61b377310be105e3a668ab4d8ad3bb87f.
  ATTACHMENT ID: 12891326

    {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: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:
    +    Get nonTenantViewGet = getTenantViewGet(catalogTable, 
DEFAULT_TENANT_BYTES, NONTENANT_VIEW_NAME);
+    Get nonTenantLinkGet = getParentChildLinkGet(catalogTable, 
DEFAULT_TENANT_BYTES, NONTENANT_VIEW_NAME);
+    //now check that the parent-child links (which have the tenant_id of the 
view's parent, but are a part of
+    //the view's metadata) are migrated in the tenant case but not the 
non-tenant. The view's tenant_id is in the
+    Assert.assertNull("Non-tenant parent-child link was not filtered when it 
should be!", filter.filter(nonTenantLinkEntry));
+    Assert.assertEquals(tenantLinkEntry.getEdit().size(), 
filter.filter(tenantLinkEntry).getEdit().size());
+    //add the parent-child link to the tenant view WAL entry, since they'll 
usually be together and they both need to
+    tenantKeyParts[4] = 
Bytes.toBytes(SchemaUtil.getTableName(SCHEMA_NAME.toUpperCase(), 
viewName.toUpperCase()));
+     * provide an efficient way for a parent table or view to look up its 
children. These rows override
+     * SYSTEM_CATALOG.COLUMN_NAME with the child tenant_id, if any, and 
contain only a single Cell, LINK_TYPE,

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

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

This message is automatically generated.

> Parent-Child linking rows in System.Catalog break tenant view replication
> -------------------------------------------------------------------------
>
>                 Key: PHOENIX-4229
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4229
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.11.0, 4.12.0
>            Reporter: Geoffrey Jacoby
>            Assignee: Geoffrey Jacoby
>             Fix For: 4.13.0
>
>         Attachments: PHOENIX-4229.patch
>
>
> PHOENIX-2051 introduced new Parent-Child linking rows to System.Catalog that 
> speed up view deletion. Unfortunately, this breaks assumptions in 
> PHOENIX-3639, which gives a way to replicate tenant views from one cluster to 
> another. (It assumes that all the metadata for a tenant view is owned by the 
> tenant -- the linking rows are not.) 
> PHOENIX-3639 was a workaround in the first place to the more fundamental 
> design problem that Phoenix places the metadata for both table schemas -- 
> which should never be replicated -- in the same table and column family as 
> the metadata for tenant views, which should be replicated. 
> Note that the linking rows also make it more difficult to ever split these 
> two datasets apart, as proposed in PHOENIX-3520.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to