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

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 5.0.0, 4.15.0
• Fix Version/s: 5.1.0, 4.16.0
• Assignee: Chinmay Kulkarni
• Reporter: Chinmay Kulkarni
• Created: 17/Sep/20 18:22
• Updated: 21/Oct/20 17:10
• Resolved: 21/Oct/20 17:10

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:

1. 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() from MetaDataEndpointImpl.mutateColumn() fails with a TableNotFoundException.
2. 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.
3. During the upgrade path for UpgradeUtil.syncUpdateCacheFreqAllIndexes(), we will just ignore any orphan views (for ex, see this), but the call to UpgradeUtil.upgradeTable() will fail with a TableNotFoundException for each orphan view.
4. 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.

Issue Links

• is related to: PHOENIX-6141 Ensure consistency between SYSTEM.CATALOG and SYSTEM.CHILD_LINK
• links to: GitHub Pull Request #903
• links to: PHOENIX-6142 Design Doc