[ 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)