Hi,
While working on revoke privilege, I realized that when a table/view/routine is dropped, we do not drop the privileges that were defined on those objects. This is a known issue and Satheesh already has plans of working on it. But, out of curiosity, I was looking at
DropTableConstantAction.executeCostantAction and found that there is following piece of code in there
DropTriggerConstantAction.dropTriggerDescriptor(lcc, dm, dd, tc, trd, activation);
So, seems like, with triggers, I might get lucky and when TRIGGERS or any other privilege is revoked on which a trigger depends, I can simply call the static method
DropTriggerConstantAction.dropTriggerDescriptor(lcc, dm, dd, tc, trd, activation);
And hence no need to go through the sql layer which will be good for performance.
I also looked at DropViewConstantAction.executeConstantAction(Activation) and found following piece of code there
vd.dropViewWork(dd, dm, lcc, tc, sd, td, false);
So, again, when a privilege is revoked such that a view will be impacted, I can simply call
So, again, when a privilege is revoked such that a view will be impacted, I can simply call
vd.dropViewWork(dd, dm, lcc, tc, sd, td, false);
when the view gets REVOKE_PRIVILEGE action from the dependency manager(I am not going into the details of what if there is another privilege which can replace the privilege being revoked and hence there is no need to drop the view. This discussion is just at high level).
when the view gets REVOKE_PRIVILEGE action from the dependency manager(I am not going into the details of what if there is another privilege which can replace the privilege being revoked and hence there is no need to drop the view. This discussion is just at high level).
So far so good for views and triggers. And most likely, no need to go through the SQL layer in order to drop them.
For constraints, there is a static method in DropConstraintConstantAction called dropConstraintAndIndex but unfortunately it does not do the work of invoking the dependency manager for all the invalidation actions. I am not sure why this static method was implemented in such a manner that only part of the work of drop constraint has been abstracted. May be someone on the list knows about this and can share their thoughts about peculiar DropConstraintConstantAction implementation.
So, in short, it seems like after all, I might not have to go through the SQL layer, most likely for views and triggers. As for constraints, I am not sure if I can avoid issuing a SQL, until I understand how(and if) the dependency work and dropConstraintAndIndex can be abstracted out into a stand alone method. If anyone has any thoughts, please share them here.
thanks,
Mamta
On 7/13/06, Daniel John Debrunner <
[EMAIL PROTECTED]> wrote:
Bryan Pendleton wrote:
> [ Possible re-send of this message; I've been having email problems,
> sorry. ]
>
>> I looked through alter table constant action to see what happens
>> when a user issues a drop constraint foreignkeyname and it seems
>> like there is lot more involved then simply calling the data
>> dictionary to drop the constraint descriptor.
>
> What about re-factoring this code and moving the extra code out of
> AlterTableConstantAction's drop constraint subroutine and into data
> dictionary's
> drop constraint routine.
I think that's pushing too much knowledge of the SQL system into the
DataDictionary. A constraint may share the underlying index with other
SQL indexes, thus dropping the constraint must check usage on the
underlying index etc.
> Then, we could share this code between alter table drop constraint, and
> revoke privilege.
The ConstantAction class for the drop constraint already contains the
logic, thus it could be the share point. Though as Mamta showed, we
already have a easy api to do the sharing, at the SQL level. All that is
required is a mechanism to run a SQL statement as another user, i think
this is something that will be required in the future, so seems like a
good thing to add.
Dan.
