[jira] [Commented] (SENTRY-1190) IMPORT TABLE silently fails if Sentry is enabled

["Reuben Kuhnert (JIRA)" <ji...@apache.org>]

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

Reuben Kuhnert commented on SENTRY-1190:
----------------------------------------

Apparently when {{HiveAuthzBindingHook}} converts a {{DDLTask}} to a {{SentryDDLFilterTask}}, the child subtasks are not also appended / converted:

{code}
      for (int i = 0; i < rootTasks.size(); i++) {
        Task<? extends Serializable> task = rootTasks.get(i);
        if (task instanceof DDLTask) {
          SentryFilterDDLTask filterTask =
              new SentryFilterDDLTask(hiveAuthzBinding, subject, stmtOperation);

          // HERE: Replace the DDLTask with a SentryFilterDDLTask - however only makes a shallow copy.
          filterTask.setWork((DDLWork)task.getWork());
 
          // Missing: filterTask.setChildTasks(task.getChildTasks());
          rootTasks.set(i, filterTask);
        }
      }
{code}

In addition, the subtasks are also {{DDLTasks}}, so I would assume that the nested subtasks should also be recursively converted to {{SentryFilterDDLTask}} (in my patch above, they are not). I would assume the other properties on the object should also be recursively deep-copied as well, but there might be some sort of validation behavior that needs to be applied to the nested properties. What should the validation behavior look like for this?

> IMPORT TABLE silently fails if Sentry is enabled
> ------------------------------------------------
>
>                 Key: SENTRY-1190
>                 URL: https://issues.apache.org/jira/browse/SENTRY-1190
>             Project: Sentry
>          Issue Type: Bug
>            Reporter: Reuben Kuhnert
>         Attachments: SENTRY-1190.01.patch
>
>
> When sentry is enabled, import table fails to copy table contents from staging area into warehouse.
> To reproduce:
> {code}
> drop table if exists testtable1;
> drop table if exists imported_testtable1;
> set hive.exec.dynamic.partition.mode=nonstrict;
> create table testtable1(
> field1 string,
> field2 string,
> field3 string,
> field4 double,
> field5 timestamp,
> field6 int)
> partitioned by(part1 string, part2 int)
> clustered by (field1) into 2 buckets
> stored as parquet;
> insert into table testtable1 partition(part1, part2) values
> ("test1", "test1", "2016-01-01", 1.11, "2016-01-01 00:00:00", 1, "part1", 1),
> ("test2", "test2", "2016-02-02", 2.22, "2016-02-02 01:00:00", 2, "part2", 2),
> ("test3", "test3", "2016-03-03", 3.33, "2016-03-03 03:00:00", 3, "part3", 3),
> ("test4", "test4", "2016-04-04", 4.44, "2016-04-04 04:00:00", 4, "part4", 4),
> ("test5", "test5", "2016-05-05", 5.55, "2016-05-05 05:00:00", 5, "part5", 5);
> select * from testtable1;
> export table testtable1 to '/user/test/testtable1export';
> import table imported_testtable1 from '/user/test/testtable1export';
> select * from imported_testtable1;
> {code}



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