[
http://issues.apache.org/jira/browse/DERBY-1539?page=comments#action_12422810 ]
Mamta A. Satoor commented on DERBY-1539:
----------------------------------------
Dan, the answer to your question "Why does the PermissionDescriptor the
dependency manager is working with only have a UUID? " is that the Dependency
Manager while working on finding dependents calls
DDdependableFinder.getDependable with just the UUID of the
PermissionDescriptor(BTW, this is generic logic and not specific to
PermissionDescriptor). And from that UUID, DDdependableFinder gets the
PermissionDescriptor using dd.getTablePermissions (dependableObjectID); on line
354. The code for dd.getTablePermissions(UUID) goes through the hashing code to
find out if a PermissionDescriptor for UUID alreadys exists in the hashtable(at
this point in the code path, we do not know tableUUID and that is why I had to
change hashCode to use UUID for generating the hash key).
One way to get around this hashing key issue for revoke privileges would be to
bypass the hash table and go straight to the system tables to get the
PermissionDescriptor using the UUID. So, we will bypass hash table only in case
of revoke privilege statement when the dependency manager is working on sending
revoke related actions to the PermissionDescriptor's dependents.
This can be implemented by changing following method in DataDictionary
public TablePermsDescriptor getTablePermissions( UUID tablePermsUUID)
throws StandardException
{
TablePermsDescriptor key = new TablePermsDescriptor( this,
tablePermsUUID);
return (TablePermsDescriptor) getPermissions( key);
}
New implementation for the method above will look as follows
public TablePermsDescriptor getTablePermissions( UUID tablePermsUUID)
throws StandardException
{
TablePermsDescriptor key = new TablePermsDescriptor( this,
tablePermsUUID);
return getUncachedTablePermsDescriptor(key);
}
With this change, we will not need the changes suggested by me on DERBY-1539,
patch DERBY1539V1hashCodeEqualsDiff.txt
The good thing about this change would be that we will not use 2 different hash
codes for the same object. The bad thing is that for revoke privilege,
dependency manager will need to always goto system tables for
PermissionDescriptor before it can send actions to dependents.
> As per the functional spec attached to DERBY-1330, a trigger should be
> dropped when a privilege required by the trigger is revoked.
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1539
> URL: http://issues.apache.org/jira/browse/DERBY-1539
> Project: Derby
> Issue Type: New Feature
> Components: SQL
> Affects Versions: 10.2.0.0
> Reporter: Mamta A. Satoor
> Assigned To: Mamta A. Satoor
> Fix For: 10.2.0.0
>
> Attachments: DERBY1539V1hashCodeEqualsDiff.txt,
> DERBY1539V1hashCodeEqualsStat.txt
>
>
> A trigger tracks its privileges requirements using Derby's Dependency
> Manager. If any one of those required privileges are revoked, the trigger
> should be dropped automatically.
> I am just creating a new jira entry here so it is easier to track sub items
> of DERBY-1330. Will link this Jira entry to DERBY-1330.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
