db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <banda...@gmail.com>
Subject Re: Grant Revoke notes ....
Date Sun, 30 Jul 2006 06:35:54 GMT
Daniel John Debrunner wrote:

>Satheesh Bandaram wrote:
>>PrivilegeInfo and GrantRevokeConstantAction is modeled much like
>>constraints are handled.... In both cases one parent statement could
>>result in multiple different database objects being created. But this
>>two levels is more needed for constraints as they can be created in
>>multiple ways, than for privileges. It should be possible to refactor,
>>but a GRANT or REVOKE action could be dealing with number of different
>>types of privileges and already deals with two now. (TablePrivilegeInfo
>>and RoutinePrivilegeInfo) It is likely that GRANT and REVOKE would deal
>>with more types of privileges in the future and this design is more
>>object oriented. But does result in extra classes, so we have to decide
>>if overhead is worth it or not.
>I was thinking of a GrantConstantAction and a RevokeConstantAction and
>their input being based upon StatementPermission objects. Replacing the
> PrivilegeInfo hierarchy with the StatementPermission one. Currently if
>I wanted to add a new Permission I have to add it in two places
>PrivilegeInfo and StatementPermission where it seems one would suffice.
This seems possible. One PrivilegeInfo may map to multiple
StatementPermission objects, but seems doable.

>Probably not incorrect, but having multiple ways to handle the same
>basic operation looked really strange to me, why are routine permissions
>only stored with the UUID of the routine, not a
>StatementRoutinePermission? In my mind a more consistent clean approach
>would be to have one hashtable, key being the UUID of the object the
>permission is on, the value being a StatementPermission. Then maybe a
>new method on StatementPermission, addToHash(HashMap map) that performs
>any lookup logic to keep that logic within the StatementPermission
>sub-class, rather than separate in CompilerContextImpl. Then ideally to
>add a new permission one simply adds the StatementPermission sub-class
>and all the general framework code just works. Currently if I add a new
>permission I will have to look for everywhere I need to change.
I like this suggestion the best! A single HashTable that hashes all
StatementPermission objects. This is pretty easily achivable in the
current framework... Just need to combine four lists into one.

Thanks for doing detailed reviews. This is one thing Grant/Revoke
patches haven't been receiving so far... code reviews. Better late than
never! Let me know if I have missed any questions or comments so far.


View raw message