phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4229) Parent-Child linking rows in System.Catalog break tenant view replication
Date Fri, 06 Oct 2017 03:10:00 GMT

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

Geoffrey Jacoby commented on PHOENIX-4229:
------------------------------------------

Thanks, [~tdsilva] - I'd looked at the link creation code earlier and missed that the second
link was created using CREATE_CHILD_LINK rather than a second use of CREATE_VIEW_LINK. You're
correct that there's only one Cell, LINK_TYPE, that needs to be replicated, and it can be
done purely on the basis of the keys. I should be able to have a fix for this JIRA up in the
next few days. 

However, it looks like the child tenant id is in position 4 of the upsert statement -- wouldn't
that make it stored in System.Catalog.COLUMN_NAME? COLUMN_FAMILY should be position 5, which
holds the schema-qualified table name. (It's not enough to know that this is a view by checking
to see if there's a parent table -- I need to know that it's a tenant-owned view.) 

This all relies on an undocumented (even in code comments, as far as I can see) assumption
that System.Catalog.COLUMN_NAME becomes CHILD_TENANT_ID in this circumstance, plus several
other changed columns. Unless you know exactly what to look for in the implementation itself,
there's nothing to call out that any column other than TENANT_ID has anything to do with tenant_ids.


As I said earlier, a document of System.Catalog's storage format, assumptions, and use cases
would be really helpful to have in these situations. It's not just self-explanatory by reading
the table's DDL, because System.Catalog is logically half a dozen tables (several of them,
like these rows, playing the role of in-table indexes) all interleaved together.  

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

Mime
View raw message