[
https://issues.apache.org/jira/browse/PHOENIX-6142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17204972#comment-17204972
]
Istvan Toth edited comment on PHOENIX-6142 at 9/30/20, 7:22 PM:
----------------------------------------------------------------
{noformat}
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch: starting with
https://issues.apache.org/jira/secure/attachment/13012354/PHOENIX-6142-4.x-v1.patch
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch:
ISSUE-branch-## = 4.x-v1
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch:
ISSUE[.##].branch =
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch:
ISSUE.branch[.##] = x-v1
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch:
ISSUE.branch[.##] = x-v1
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch:
ISSUE-branch[.##] = 4.x-v1
19:28:51 [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch:
ISSUE-branch[.##] = 4{noformat}
Yetus indeed couldn't determine the branch, and using dots instead is a good
idea.
However, I'd suggest simply opening a GitHub PR. That's easier, and you get
prettier Yetus output.
was (Author: stoty):
*19:28:51* [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch*19:28:51*
[Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch: starting with
[^PHOENIX-6142-4.x-v1.patch]*19:28:51* [Wed Sep 30 17:28:51 UTC 2020 DEBUG]:
Determine branch: ISSUE-branch-## = 4.x-v1*19:28:51* [Wed Sep 30 17:28:51 UTC
2020 DEBUG]: Determine branch: ISSUE[.##].branch = *19:28:51* [Wed Sep 30
17:28:51 UTC 2020 DEBUG]: Determine branch: ISSUE.branch[.##] = x-v1*19:28:51*
[Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch: ISSUE.branch[.##] =
x-v1*19:28:51* [Wed Sep 30 17:28:51 UTC 2020 DEBUG]: Determine branch:
ISSUE-branch[.##] = 4.x-v1*19:28:51* [Wed Sep 30 17:28:51 UTC 2020 DEBUG]:
Determine branch: ISSUE-branch[.##] = 4
Yetus indeed couldn't determine the branch, and using dots instead is a good
idea.
However, I'd suggest simply opening a GitHub PR. That's easier, and you get
prettier Yetus output.
> 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#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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
