Hi Bryan,
Maybe someone with more knowledge of dependency manager can provide more information but I think the reason we are handling views through dependency system is that there might be other objects(say another view, prepared statement) dependent on that view and they all need to be notified of the view invalidation. As for the trigger, there can't be any other object that can depend on that trigger and hence we can bypass the dependency system and go straight to DropTableConstantAction code.
Mamta
On 9/11/06, Bryan Pendleton <[EMAIL PROTECTED]> wrote:
> Satheesh had added some code as part of "(DERBY-1543) Address two
> remaining issues with GRANT/REVOKE functionality: 1) Add warning when
> sqlAuthorization is on with authentication off 2) Drop permission
> descriptors when objects they cover are dropped." to cleanup 3
> permissions related system tables when a table/routine is dropped. Maybe
> something similar is required when a column is dropped from a table.
Thanks, Mamta! Yes, this is a very interesting and relevant change for
the issue I'm struggling with. It seems like DERBY-1543 could have been
implemented using the dependency manager, but was not.
I will investigate extending the techniques used by DERBY-1543 to cover
dropping a column, as you suggest.
In the meantime, I'm still rather puzzled regarding the more generic
question of when the various data dictionary objects use the SYSDEPENDS
table and the Dependency Manager routines, and when they do not. If anybody
has insight into the history or architecture here, that would be greatly
appreciated. For example, why is dropping a dependent VIEW driven out of
ViewDescriptor.makeInvalid, but dropping a dependent TRIGGER is driven by
direct calls in the DropTableConstantAction code?
There's a definite difference in the overall technique, and I'm not
grasping the idea about when to use the one and when to use the other.
thanks,
bryan
