[jira] [Updated] (DRILL-5572) Confusing userName property in AbstractBase

["Paul Rogers (JIRA)" <ji...@apache.org>]

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