[
https://issues.apache.org/jira/browse/PHOENIX-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16508740#comment-16508740
]
Geoffrey Jacoby edited comment on PHOENIX-4195 at 6/11/18 9:06 PM:
-------------------------------------------------------------------
[~jamestaylor] - I agree that stuff like indexes on views will break if you
delete through the base table. However, I disagree that this is a reason to
disallow deleting a view row through a base table. It's a reason to get
PHOENIX-1499 done.
The fundamental issue here is the decision Phoenix makes that global
connections can't see (some) tenant data or metadata. I think this assumption
creates a lot of problems, and this JIRA is just one symptom.
In general, I don't believe that a tenant should be able to create data that a
global connection can't delete or can't see. A tenant connection should limit
your power, not give you superpowers. It would be like letting an ordinary user
on a Unix system create files that root can't delete without using su.
A better abstraction would be the one Phoenix already uses in its JDBC metadata
API: each tenant gets a "catalog" to put views and view indexes in, and a
tenant connection gets the right to query global tables (with auto-filtering on
tenant id), and views that are in that tenant's catalog. A global connection
can see everything, with naming ambiguity taken care of by fully qualifying
names as <catalog / tenant>.<schema>.<view name>.
was (Author: gjacoby):
[~jamestaylor] - I agree that stuff like indexes on views will break if you
delete through the base table. However, I disagree that this is a reason to
disallow deleting a view row through a base table. It's a reason to get
PHOENIX-1499 done.
The fundamental problem here is the decision Phoenix makes that global
connections can't see tenant data or metadata. I think this assumption creates
a lot of problems, and this JIRA is just one symptom.
In general, I don't believe that a tenant should be able to create data that a
global connection can't delete or can't see. A tenant connection should limit
your power, not give you superpowers. It would be like letting an ordinary user
on a Unix system create files that root can't delete without using su.
A better abstraction would be the one Phoenix already uses in its JDBC metadata
API: each tenant gets a "catalog" to put views and view indexes in, and a
tenant connection gets the right to query global tables (with auto-filtering on
tenant id), and views that are in that tenant's catalog. A global connection
can see everything, with naming ambiguity taken care of by fully qualifying
names as <catalog / tenant>.<schema>.<view name>.
> 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)
