[
https://issues.apache.org/jira/browse/PHOENIX-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109753#comment-14109753
]
Jan Fernando commented on PHOENIX-1098:
---------------------------------------
Discussed this with [~jamestaylor] and here is the proposed solution.
Given that until the SYSTEM.CATALOG table gets very, very large all metadata
will be colocated on one region we will optimize for this situation. We will
get all the tenant ids for all child views and determine whether all views and
all the parent table metadata are in the same region. If they we will drop them
using the all or nothing approach we use for table and column metadata rows.
In the event that SYSTEM.CATALOG has split and some tenant views are not
colocated with the parent table records we will try and delete the view
metadata from all the regions first, doing the region where the parent table is
located last. If any of these deletes fail we will throw and bubble up an
exception to the caller. At this point some tenant views may have been deleted
and others not, but the parent table will not have been affected. Callers will
need to retry the DROP TABLE until it succeeds to guarantee that the table and
all it's views have been deleted.
> Support CASCADE option on DROP TABLE that drops all VIEWs
> ---------------------------------------------------------
>
> Key: PHOENIX-1098
> URL: https://issues.apache.org/jira/browse/PHOENIX-1098
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Jan Fernando
>
> It's inconvenient to have to manually drop all of the views of a multi-tenant
> table before being able to drop the table. We should support a CASCADE option
> on DROP TABLE which automatically does this, like this:
> DROP TABLE foo CASCADE
--
This message was sent by Atlassian JIRA
(v6.2#6252)
