[ https://issues.apache.org/jira/browse/PHOENIX-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193742#comment-16193742 ]
Geoffrey Jacoby commented on PHOENIX-4229: ------------------------------------------ It does look like the link would always have a LINK_TYPE of LinkType.CHILD_TABLE, but there doesn't seem to be a way to tell from that Cell that it's a CHILD_TABLE link attached to a tenant-owned view, as opposed to a global view. (If it's a view on a tenant-view, so that tenant_id in the PK is non-zero, that would actually be easy to catch -- but that first parent-child link from the global table to the child tenant-owned view is the problem.) > 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 > > 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)