You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Chinmay Kulkarni (Jira)" <ji...@apache.org> on 2020/10/13 19:07:00 UTC

[jira] [Updated] (PHOENIX-6142) Make DDL operations resilient to orphan parent->child linking rows in SYSTEM.CHILD_LINK

     [ https://issues.apache.org/jira/browse/PHOENIX-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chinmay Kulkarni updated PHOENIX-6142:
--------------------------------------
    Description: 
We are targeting PHOENIX-6141 for 4.17. Until we have it, we should aim at making DDL operations resilient to orphan parent->child linking rows. DDL operations identified which can fail due to orphan rows are:
 # Any ALTER TABLE ADD/DROP/SET calls on the base table T will fail if there are orphan links from T to some already dropped view. This happens because the call to [MetaDataEndpointImpl.findAllChildViews()|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2142] from [MetaDataEndpointImpl.mutateColumn()|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2592] fails with a TableNotFoundException.
 # Any DROP TABLE/VIEW call without CASCADE will fail even though there are actually no child views since the orphan rows wrongly indicate that there are child views.
 # During the upgrade path for UpgradeUtil.syncUpdateCacheFreqAllIndexes(), we will just ignore any orphan views (for ex, see [this|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java#L1368-L1374]), but the call to UpgradeUtil.upgradeTable() will fail with a TableNotFoundException for each orphan view.
# During a CREATE TABLE/VIEW, we try to drop any views from the previous life of that table/view, however we might end up dropping a legitimate view (with the same name) which is on another table/view because of this.

Before dropping any views that we see from a parent->child link, we need to ensure that the view is in fact a child view of the same table/view we think it is an orphan of.

  was:
We are targeting PHOENIX-6141 for 4.17. Until we have it, we should aim at making DDL operations resilient to orphan parent->child linking rows. DDL operations identified which can fail due to orphan rows are:
 # Any ALTER TABLE ADD/DROP/SET calls on the base table T will fail if there are orphan links from T to some already dropped view. This happens because the call to [MetaDataEndpointImpl.findAllChildViews()|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2142] from [MetaDataEndpointImpl.mutateColumn()|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L259] fails with a TableNotFoundException.
 # Any DROP TABLE/VIEW call without CASCADE will fail even though there are actually no child views since the orphan rows wrongly indicate that there are child views.
 # During the upgrade path for UpgradeUtil.syncUpdateCacheFreqAllIndexes(), we will just ignore any orphan views (for ex, see [this|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java#L1368-L1374]), but the call to UpgradeUtil.upgradeTable() will fail with a TableNotFoundException for each orphan view.
# During a CREATE TABLE/VIEW, we try to drop any views from the previous life of that table/view, however we might end up dropping a legitimate view (with the same name) which is on another table/view because of this.

Before dropping any views that we see from a parent->child link, we need to ensure that the view is in fact a child view of the same table/view we think it is an orphan of.


> Make DDL operations resilient to orphan parent->child linking rows in SYSTEM.CHILD_LINK
> ---------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-6142
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-6142
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 5.0.0, 4.15.0
>            Reporter: Chinmay Kulkarni
>            Assignee: Chinmay Kulkarni
>            Priority: Blocker
>             Fix For: 5.1.0, 4.16.0
>
>         Attachments: PHOENIX-6142-4.x-v1.patch, PHOENIX-6142.4.x.v2.patch
>
>
> We are targeting PHOENIX-6141 for 4.17. Until we have it, we should aim at making DDL operations resilient to orphan parent->child linking rows. DDL operations identified which can fail due to orphan rows are:
>  # Any ALTER TABLE ADD/DROP/SET calls on the base table T will fail if there are orphan links from T to some already dropped view. This happens because the call to [MetaDataEndpointImpl.findAllChildViews()|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2142] from [MetaDataEndpointImpl.mutateColumn()|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2592] fails with a TableNotFoundException.
>  # Any DROP TABLE/VIEW call without CASCADE will fail even though there are actually no child views since the orphan rows wrongly indicate that there are child views.
>  # During the upgrade path for UpgradeUtil.syncUpdateCacheFreqAllIndexes(), we will just ignore any orphan views (for ex, see [this|https://github.com/apache/phoenix/blob/fece8e69b9c03c80db7a0801d99e5de31fe15ffa/phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java#L1368-L1374]), but the call to UpgradeUtil.upgradeTable() will fail with a TableNotFoundException for each orphan view.
> # During a CREATE TABLE/VIEW, we try to drop any views from the previous life of that table/view, however we might end up dropping a legitimate view (with the same name) which is on another table/view because of this.
> Before dropping any views that we see from a parent->child link, we need to ensure that the view is in fact a child view of the same table/view we think it is an orphan of.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)