phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoffrey Jacoby (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4195) PHOENIX-4195 Deleting view rows with extended PKs through the base table silently fails
Date Tue, 12 Jun 2018 22:26:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16510321#comment-16510321
] 

Geoffrey Jacoby commented on PHOENIX-4195:
------------------------------------------

[~jamestaylor] - if the intention is to make it impossible to corrupt a view index, wouldn't
you have to disable both UPSERTs and DELETEs to any multi-tenant table from any global connection?
Even if you had a hasChildViews boolean in PTable, any global connection write would have
a potential race condition if another tenant-connection was trying to create a view + view
index, wouldn't it?

>From a usability standpoint, however, that would be problematic, because there are many
important use cases in which most users access a multi-tenant table through tenant connections,
but bulk or admin operations are done cross-tenant by global connections. 

And even if we do disable writes from global connections to multi-tenant tables, isn't there
still a race condition where another client could be creating a _global_ view on a non-multi-tenant
table that would cause problems when deleting or mutating the base table?

> PHOENIX-4195 Deleting view rows with extended PKs through the base table silently fails
> ---------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-4195
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4195
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Thomas D'Silva
>            Assignee: Geoffrey Jacoby
>            Priority: Major
>         Attachments: test.diff
>
>
> The attached test fails.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message