drill-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Rogers (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DRILL-5572) Redundant user name property in AbstractBase, EasySubScan
Date Tue, 06 Jun 2017 23:45:18 GMT

     [ https://issues.apache.org/jira/browse/DRILL-5572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Paul Rogers updated DRILL-5572:
-------------------------------
    Description: 
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.


  was:
In Drill physical operators:




> Redundant user name property in AbstractBase, EasySubScan
> ---------------------------------------------------------
>
>                 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)

Mime
View raw message