Mamta Satoor wrote:
Satheesh, I was looking through the code last night and saw
following comment, about external security info flag, in
CreateAliasNode.init line 195
// GrantRevoke TODO: Figure out how to save external
security info. Putting this in
// RoutineAliasInfo may not be the best long term solution
It seems like RoutineAliasInfo will be the logical place to keep this
external security information, similar to the way we keep other
information like called on null input, parameter count etc. Did you
have reservations about this approach because we want to move away from
using objects in the system tables (which in this case is AliasInfo in
SYSALIASES table)?
Here are some of my concerns about adding another field to
RoutineAliasInfo.
- It would become harder to extract this info from RoutineAliasInfo
as it is a Java object for any metadata processing... like in dblook or
for other GUI tools. We would have to document how RoutineAliasInfo
gets generated as a character type and maintain that format in the
future.
- Have to support existing RoutineAliasInfo instances created in
existing databases. You would have to introduce a new RoutineAliasInfo
version or add a new mapping to another java object.
It may be cleaner to add a new column to sysaliases table, but it can
also be done as RoutineAliasInfo field.
Satheesh
thanks,
Mamta
On 2/21/06, Satheesh Bandaram <[EMAIL PROTECTED]
> wrote:
Thanks
for picking this up. A sub-task under DERBY-464 sounds good.
Satheesh
Mamta Satoor wrote:
> Hi,
>
> Satheesh has added the parser support for EXTERNAL SECURITY
DEFINER |
> EXTERNAL SECURITY INVOKER on a routine (function or procedure). eg
> from lang/grantRevoke.sql test
> CREATE PROCEDURE AUTH_TEST.addUserUtility(IN userName VARCHAR(50),
IN
> permission VARCHAR(22))
> LANGUAGE JAVA PARAMETER STYLE JAVA
> EXTERNAL SECURITY INVOKER
> EXTERNAL NAME 'org.apache.derby.database.UserUtility.add ';
>
> But this information about INVOKER vs DEFINER doesn't get stored
in
> any system table. I am looking into finishing up this subtask to
see
> what may be required during compile, execute and upgrade times for
> this subtask. Will send more information as I make more progress.
>
> thanks,
> Mamta
>
> ps Will it be useful to create a subtask of Derby-464 to keep
track of
> this work?
|
