db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Revoke REFERENCES privilege and drop foreign key constraint
Date Fri, 14 Jul 2006 00:17:59 GMT

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,

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,
And hence no need to go through the sql layer which will be good for

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

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.


On 7/13/06, Daniel John Debrunner <djd@apache.org> 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.

View raw message