[
https://issues.apache.org/jira/browse/PHOENIX-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110688#comment-17110688
]
Chinmay Kulkarni commented on PHOENIX-5404:
-------------------------------------------
We will now break down a CREATE TABLE/VIEW into 4 client-side RPCs:
# RPC to SYSTEM.CHILD_LINK region if it's a CREATE VIEW to add links from the
view's parent to itself
# RPC to SYSTEM.CATALOG to write header rows, column metadata, etc. (main
stuff inside MetaDataEndpointImpl#createTable)
# RPC to SYSTEM.CHILD_LINK to issue a scan to get the child views of the
current table/view from that table/view's past life
# RPC to SYSTEM.CATALOG to issue DROP VIEW CASCADE commands for each of the
child views
1 and 2 already exist. This Jira introduces 3 and 4 instead of the
server-server RPCs. Note that it's hard to piggy-back changes for a single
table in 1 RPC since the order of the above RPCs matters i.e. we can't do 3.
until 2. concludes that the table/view doesn't already exist (otherwise we
might drop legitimate child views and not views from a previous life of that
table/view). We also obviously can't do 4. until we get the list of child views
as an output from 3.
If dropping the child views fails, currently since the call is server-server,
it would prevent writing even the header rows, etc. in SYSTEM.CATALOG and
return an error to the client (which is good).
BUT by moving this to the client, since 3 and 4 have to be triggered after 2,
if either 3 or 4 fails, header rows for that table/view would've already been
written to SYSTEM.CATALOG (I don't think we can easily rollback). At this
point, throwing an error to the client (to maintain current behavior in the
case dropChildViews fails) doesn't make much sense since the damage is already
done. A subsequent CREATE TABLE/VIEW would fail since we would conclude that
that table already exists.
I propose we make RPCs 3 and 4 a best-effort and log in case of failure, but
return the code of RPC 2 to the client. The best approach is obviously if we
refactored all of our metadata changes such that we could reduce the number of
RPCs and have potentially transaction semantics, but that is a much larger
change :)
Does this solution seem ok [~larsh] [~kozdemir] [~gjacoby] [~tdsilva]?
> Move check to client side to see if there are any child views that need to be
> dropped while receating a table/view
> ------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-5404
> URL: https://issues.apache.org/jira/browse/PHOENIX-5404
> Project: Phoenix
> Issue Type: Sub-task
> Affects Versions: 5.0.0, 4.15.0
> Reporter: Thomas D'Silva
> Assignee: Chinmay Kulkarni
> Priority: Major
> Fix For: 5.1.0, 4.16.0
>
>
> Remove {{ViewUtil.dropChildViews(env, tenantIdBytes, schemaName,
> tableName);}} call in MetdataEndpointImpl.createTable
> While creating a table or view we need to ensure that are not any child views
> that haven't been clean up by the DropChildView task yet. Move this check to
> the client (issue a scan against SYSTEM.CHILD_LINK to see if a single linking
> row exists).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
