Mailing-List: contact issues-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
Date: Tue, 6 Jun 2017 23:45:18 +0000 (UTC)
From: "Paul Rogers (JIRA)" <jira@apache.org>
To: issues@drill.apache.org
Message-ID: <JIRA.13077838.1496792279000.12134.1496792718359@Atlassian.JIRA>
In-Reply-To: <JIRA.13077838.1496792279000@Atlassian.JIRA>
References: <JIRA.13077838.1496792279000@Atlassian.JIRA> <JIRA.13077838.1496792279201@jira-lw-us.apache.org>
Subject: [jira] [Updated] (DRILL-5572) Redundant user name property in
 AbstractBase, EasySubScan
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 06 Jun 2017 23:45:23 -0000


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