[
https://issues.apache.org/jira/browse/PHOENIX-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193405#comment-16193405
]
Geoffrey Jacoby edited comment on PHOENIX-4229 at 10/5/17 6:39 PM:
-------------------------------------------------------------------
[~jamestaylor] (or [~tdsilva]) - could you be more specific? What's the actual
predicate I should be checking for? tenant_id == 0x0 and <some other
System.Catalog primary key column> == <a particular tenant> ? What's the second
column?
I'm sure I can reverse engineer it from PHOENIX-2051, but it's a decent-sized,
complex patch and would save me some time if you know the answer offhand.
In general, a doc that actually explains the column and row layout of
System.Catalog would be helpful, since it seems like every time someone works
with it a good deal of reverse engineering is needed.
was (Author: gjacoby):
[~jamestaylor] (or [~tdsilva]) - could you be more specific? What's the actual
predicate I should be checking for? tenant_id == 0x0 and <some other
System.Catalog primary key column> == tenant_id? What's the second column?
I'm sure I can reverse engineer it from PHOENIX-2051, but it's a decent-sized,
complex patch and would save me some time if you know the answer offhand.
In general, a doc that actually explains the column and row layout of
System.Catalog would be helpful, since it seems like every time someone works
with it a good deal of reverse engineering is needed.
> 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)
