[
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.
