db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satheesh Bandaram <banda...@gmail.com>
Subject Grant Revoke notes ....
Date Tue, 25 Jul 2006 18:28:46 GMT
Thanks for creating this GrantRevoke notes, Dan. Here are some comments
on some of your points.


1) "PrivilegeInfo looks very much like a constant action, the constant
action for grant/revoke is more or less just an empty object that calls
the execute method on PrivilegeInfo. Should this code be re-factored to
have all the logic in a constant action, to match the pattern of other
DDL statements."

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.

2) "PermissionsDescriptor object passed in is reset each time with a
different grantee - does this match the intended purpose of such
descriptors which are TupleDescriptors and match a single row in the

This can be changed.. probably should be.

3) "Too many ways of representing permissions, PrivilegeInfo,
StatementPermission, PermissionDescriptor, UUID. Possible solution"

PermissionDescriptors are more like TableDescriptors... represent a
granted privilege present in system tables. Currently there are
TablePermDescriptors, RoutinePermDescriptors and  ColPermDescriptors,
representing each of three new system catalogs. (RequiredPermDescriptor
would go away) StatementPermission represents required database object
access that need to be verified for permission at runtime. Note that
these access descriptors could be for objects that don't have
PermissionDescriptors... like StatementSchemaPermission object and also
don't have fields like grantor/grantee/grantWithGrant etc. There is no
1-1 mapping in their purpose, I think, but some refactoring may be
possible. Result could turn out be as messier if not more, but might
reduce some footprint.

4) Items about HashMaps/HashSet...

Possibly some improvement can be made here, but nothing seems incorrect.
Hashing is done to make sure only one StatementPermission object is
created for a given type of access on same database object. Otherwise,
we could create multiple access checks and perform same privilege
checking multiple times.

Guess the *main *concern is multiple objects being created and see if
they can be refactored, right?


View raw message