[ 
https://issues.apache.org/jira/browse/DERBY-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491986
 ] 

Dyre Tjeldvoll commented on DERBY-2594:
---------------------------------------

There is a typo in the description. The last sentence should read "...this will 
change when language result sets are reused".

As an initial experiment I've tried to modify DependencyManager.invalidateFor() 
so that it detects when REVOKE_PRIVILEGE is sent to a TablePermsDescriptor, and 
then adds an explicit call to invalidateFor() on the TableDescriptor:

coreInvalidateFor(p, action, lcc);
                        if (p instanceof TablePermsDescriptor && 
                            action == DependencyManager.REVOKE_PRIVILEGE) {
                                final TablePermsDescriptor tpd = 
(TablePermsDescriptor) p;
                                final TableDescriptor td = 
dd.getTableDescriptor(tpd.getTableUUID());
                                coreInvalidateFor(td, 
DependencyManager.INTERNAL_RECOMPILE_REQUEST, lcc);

But this fails with

Caused by: java.sql.SQLException: Operation 'INTERNAL RECOMPILE REQUEST' cannot 
be performed on object 'TSAT' because VIEW 'V1' is dependent on that object.

> Revoking a privilege from a table should invalidate statements dependent on 
> that table
> --------------------------------------------------------------------------------------
>
>                 Key: DERBY-2594
>                 URL: https://issues.apache.org/jira/browse/DERBY-2594
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.2.1.6
>            Reporter: Dyre Tjeldvoll
>         Assigned To: Dyre Tjeldvoll
>
> Revoking a privilege on a table will currently cause the 
> DependencyManager.invalidateFor() to be called on the table's 
> TablePermsDescriptor with the action=REVOKE_PRIVILEGE. However, the prepared 
> statements that refer to that table are dependents of the table's 
> TableDescriptor, but NOT its TablePermsDescriptor, so the statements are not 
> invalidated after revoke.
> This problem is currently hidden by the fact that authorization is checked on 
> every execution, but this will change when language result sets are no longer 
> reused (see DERBY-827). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to