Thanks for your comments, Dan. I will update the spec, but some answers below:
"This property could be set either as a system property in derby.properties file or as application property." This needs re-wording, system properties are set as JVM system proiperties, application properties is what is used to describe properties in derby.properties. You could just say 'this is a standard Derby property"
OK... Tuning guide refers to both as System-wide properties... System-wide properties set programmatically and System-wide properties set in derby.properties.
- The design doesn't contain any mention of modifications to the statement dependencies. It may be (after thinking about it for 10 seconds) that any grant/revoke statement does not need to invalidate any DML compiled statements. It would be good to state this and the reasons why.
Right... Grant and Revoke statements don't need to invalidate any existing compiled statements. This is because the compiled plan doesn't assume if any permissions are granted or not... Compilation only notes required object accesses to execute a statement. Only at runtime, these checks are performed. I will add more info to design section.
- I couldn't see where you are storing the owner of the database
Any ideas where it could be? I haven't coded that part. I was thinking of using an internal property to store the database owner. Are there any internal use only properties in Derby currently? I thought boot password is kind of stored like this?
- Can you expand on the design around the StatementPermission class and its sub-classes. Which methods are invovled in making permission checks., The Javadoc for the check method in StatementPermission doesn't say anything. The methods have some funky equals methods with no javadoc, without understanding more it looks like equals is being overloaded for no good reason.
StatementPermission has the following hieraracy.. not sure if this will show correctly in text
All implement check() interface that is used to invoke permission checking for that access descriptor. Access descriptors already know what they need to check for and are passed current user authorizationId.
The equals() method is used to check if an access descriptor is already created for the specific access. For example, a query may have multiple references to same table. No need to create multiple access descriptors for the same table for the same kind of access. This becomes more important as each and every column referenced may try to add an access descriptor for the table in question.
I will add these details to the design part of the spec.