db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2594) Revoking a privilege from an SQL Object should invalidate statements dependent on that object
Date Thu, 26 Apr 2007 18:06:15 GMT

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

Daniel John Debrunner commented on DERBY-2594:
----------------------------------------------

Why is a new action required (REVOKE_RECOMPILE)?
Isn't the same amount of work to make other non GenericPreparedStatements dependents handle
this as handling the existing INTERNAL_RECOMPILE_REQUEST notification?

>. That GrantRevokeCA actually calls DM.invalidateFor() on all
  relevant Providers (SQL object descriptors) 

I think this is best handled in an OO approach, the TablePrivilege object  should be sending
out the recompile invalidation on the table,
not the callers. Ie. when it is invalidated with a REVOKE, then it sends out a invalidate
on the table with recompile. 


> Revoking a privilege from an SQL Object should invalidate statements dependent on that
object
> ---------------------------------------------------------------------------------------------
>
>                 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.


Mime
View raw message