You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@drill.apache.org by "Nagarajan Chinnasamy (JIRA)" <ji...@apache.org> on 2016/12/15 20:53:58 UTC

[jira] [Comment Edited] (DRILL-5132) Context based dynamic parameterization of views

    [ https://issues.apache.org/jira/browse/DRILL-5132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752459#comment-15752459 ] 

Nagarajan Chinnasamy edited comment on DRILL-5132 at 12/15/16 8:53 PM:
-----------------------------------------------------------------------

Lets say we have a *pre-defined documented place* where a *session based temporary table* named *context* is created with the following columns:

{code}
session_id, context_type, context_key, context_value
{code}

and say this context table is transparently populated with context based values *as and when a user connection (session) is established*

then a view created with the following kind of query:

{code}
select
   a.field as a_field
   b.field as b_field
from
   a_table as a
left join
   b_table as b
on
   a.bId = b.Id
inner join
   context c
on
   c.session_id=session_id() and
   c.context_type='custom' and
   c.context_key='tenandId" and
   c.context_value=a.tenantId
{code}

This becomes a query that has built-in support for dynamic parameterization that only exposes records of the current tenantId of the current context.

The purpose of context_type column is to inject system defined context values and custom context values.

Custom context values can be obtained through a *custom-context-provider* (like custom-authenticator)

System defined context_types can be *drill.system*, *drill.query* etc.

Does that sound elegant and sensible??!!!! :)


was (Author: nagarajanchinnasamy):
Lets say we have a *pre-defined documented place* where a *session based temporary table* named *context* is created with the following columns:

{code}
session_id, context_type, context_key, context_value
{code}

and say this context table is transparently populated with context based values *as and when a user connection (session) is established*

then a view created with the following kind of query:

{code}
select
   a.field as a_field
   b.field as b_field
from
   a_table as a
left join
   b_table as b
on
   a.bId = b.Id
inner join
   context c
on
   c.session_id=session_id() and
   c.context_type="custom" and
   c.context_key='tenandId" and
   c.context_value=a.tenantId
{code}

This becomes a query that has built-in support for dynamic parameterization that only exposes records of the current tenantId of the current context.

The purpose of context_type column is to inject system defined context values and custom context values.

Custom context values can be obtained through a *custom-context-provider* (like custom-authenticator)

Does that sound elegant and sensible??!!!! :)

> Context based dynamic parameterization of views
> -----------------------------------------------
>
>                 Key: DRILL-5132
>                 URL: https://issues.apache.org/jira/browse/DRILL-5132
>             Project: Apache Drill
>          Issue Type: Wish
>          Components:  Server
>            Reporter: Nagarajan Chinnasamy
>            Priority: Critical
>              Labels: authentication, context, isolation, multi-tenancy
>
> Its known that Views in SQL cannot have dynamic parameters/variables.  Please refer to [Justin Swanhart|http://stackoverflow.com/users/679236/justin-swanhart]'s response to [this SO question|http://stackoverflow.com/questions/2281890/can-i-create-view-with-parameter-in-mysql] in handling dynamic parameterization of views. 
> [The PR #685|https://github.com/apache/drill/pull/685] [DRILL-5043|https://issues.apache.org/jira/browse/DRILL-5043?filter=-2] originated based on this requirement so that we could build views that can dynamically filter records based on some dynamic values (like current tenant-id, user role etc.) 
> *Since Drill's basic unit is a View... having such built-in support can bring in dynamism into the whole game.*
> This feature can be utilized for:
> * *Data Isolation in Shared Multi-Tenant environments* based on Custom Tenant Discriminator Column
> * *Data Protection in building Chained Views* with Custom Dynamic Filters
> I will post further design details in the comments....



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)