[
https://issues.apache.org/jira/browse/DRILL-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Rogers updated DRILL-5572:
-------------------------------
Summary: Confusing userName property in AbstractBase (was: Redundant user
name property in AbstractBase, EasySubScan)
> Confusing userName property in AbstractBase
> -------------------------------------------
>
> Key: DRILL-5572
> URL: https://issues.apache.org/jira/browse/DRILL-5572
> Project: Apache Drill
> Issue Type: Improvement
> Affects Versions: 1.8.0
> Reporter: Paul Rogers
> Priority: Minor
>
> In Drill physical operators:
> {code}
> public abstract class AbstractBase implements PhysicalOperator {
> ...
> private final String userName;
> ...
> public AbstractBase(String userName) {
> this.userName = userName;
> }
> {code}
> But, most operators don't use the user name. Indeed, what does it mean to run
> a sort or filter as some user? The only operators that need a user name are
> those that read from, or write to the OS.
> So, rather than putting the name on the base class, and set it only for
> readers and writers, create a new intermediate class, `ImpersonatingOperator`
> that is the parent for operations that can impersonate another user.
> Further, if the entire query runs as a single user, the user name should be a
> property of the query. The only time we need per-operator user information is
> if we use view security:
> {code}
> SELECT a.x, a.y, b.m, b.n FROM a, b WHERE a.x = b.x
> {code}
> Here both a and b are views, and the access to the tables is specified by the
> owner of the view. This requires per-operator user name. But, the property
> should be "accessUser" since "userName" is too generic; it doesn't say which
> user is described.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
