Na Li commented on SENTRY-2143:

[~akolb] It is correct behavior for 
SentrySyncHMSNotificationsPostEventListener.syncNotificationEvents to do 
nothing when notification ID is not set because the sync blocks on the given 
notification ID. When this info is not available, we can not block on a given 
notification ID

There are two types of lisenters: transactional listener 
("hive.metastore.transactional.event.listeners"), which stores event ID  and 
post event listener ("hive.metastore.event.listeners"), which can block on a 
given notification ID. 

I know the notification ID is not set because I changed test code to verify if 
table rename causes failed test succeed. When they behave the same, I step into 
code and found notification ID not set in alter table event, and 
SentrySyncHMSNotificationsPostEventListener.syncNotificationEvents does not do 
anything accordingly

> Table renames should synchronize with Sentry
> --------------------------------------------
>                 Key: SENTRY-2143
>                 URL: https://issues.apache.org/jira/browse/SENTRY-2143
>             Project: Sentry
>          Issue Type: Bug
>          Components: Sentry
>    Affects Versions: 2.1.0
>            Reporter: Alexander Kolbasov
>            Assignee: Na Li
>            Priority: Major
>         Attachments: SENTRY-2143.001.patch, SENTRY-2143.002.patch, 
> SENTRY-2143.003.patch, SENTRY-2143.004.patch
> Currently table renames are not synchronized from Hive (while table 
> creates/drops are). This creates a problem since the renamed table doesn't 
> have correct privileges for a bit until it is processed by Sentry. So 
> perfectly valid scripts that rename tables and expect the rename table to 
> retain the privileges are going to fail.
> The fix is to update {{SentrySyncHMSNotificationsPostEventListener}} to 
> synchronize table renames as well.

This message was sent by Atlassian JIRA

Reply via email to