Hi David, I did post the patch for review... I followed up the post after few days to invite anyone to review again. That time I said I could wait for review comments or submit then address comments. I also said I would submit the patch over the next weekend. Since no one replied that either they want more time or going to review before submission, I submitted the change.
http://article.gmane.org/gmane.comp.apache.db.derby.devel/11113 http://article.gmane.org/gmane.comp.apache.db.derby.devel/11012 I am willing to address any review comments anyone has. Should I have waited for more time? I wanted to submit the changes over the weekend to minimize any disruptions... Satheesh David W. Van Couvering wrote: > Hi, Satheesh. I am still learning the Apache Way, so I wanted to get > some clarity on how things are generally done. > > I know that committers have the merit and trust to commit what they > want. I had generally assumed, however, that a large change like this > should be posted as a patch for review before being committed. > > Is the approach that we do an svn diff of the change revision and we > can send you comments, and you can make changes in response? > > Thanks, > > David > > Satheesh Bandaram (JIRA) wrote: > >> [ >> http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12360186 >> ] >> Satheesh Bandaram commented on DERBY-464: >> ----------------------------------------- >> >> I have submitted Grant and Revoke, Part I to trunk. Let me know if >> anyone would like to join developing remaining parts. It is possible >> to coordinate development using a Wiki. >> This Phase I implements: >> >> * Grant/Revoke DDL parsing and execution >> * Addition of several new system tables to hold the system >> metadata. I will update my spec to include detailed schema for new >> system tables, so that they can be included in 10.2 documentation. >> * Enhancing the syntax for routine creation to include >> external-security clause >> * Very simple tests to cover only the DDL. I would be expanding on >> the testing in the later submissions, including a JUnit test suite. >> * Grant/Revoke DDL is only supported if >> derby.database.defaultConnectionMode property is set to 'sqlStandard'. >> >> Pending items from Phase I: >> >> 1. dblook needs to be enhanced to emit DDL for grant statements. >> 2. Enhanced JUnit based test suite with many more tests. 3. >> Some implementation improvements possible with the current patch. It >> should be possible to combine several new nodes being added, to >> reduce number of nodes and hence foot print. Also, the patch adds a >> Java object to new system tables. While Derby already has some java >> objects in its system tables, I think, we should discourage adding >> new java objects to catalogs. Since Java objects can't be used in SQL >> easily, this makes metadata harder to use. I will explore rewriting >> SYSCOLPERMS and SYSREQUIREDPERM to not use FormattableBitSet type. >> This can be done by having multiple entries in these catalogs for >> each column referenced. >> 4. Updating specification to include schema for new system tables. >> 5. Need to change how property defaultConnectionMode is set and/or >> used. >> 6. Enhance system tables to store external security clause >> specification. >> >> I am also working on Grant and Revoke, Phase II. This will implement >> permission checking for DML statement. Hopefully I will have >> something to submit by end of January to complete Phase I and Phase II. >> >> Also need to support upgrade and migration of legacy databases and >> update JDBC metadata. >> >> Let me know if I missed anything else. >> >> >> >>> Enhance Derby by adding grant/revoke support. Grant/Revoke provide >>> finner level of privileges than currently provided by Derby that is >>> especially useful in network configurations. >>> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >>> >>> >>> Key: DERBY-464 >>> URL: http://issues.apache.org/jira/browse/DERBY-464 >>> Project: Derby >>> Type: New Feature >>> Components: SQL >>> Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0 >>> Environment: generic >>> Reporter: Satheesh Bandaram >>> Assignee: Satheesh Bandaram >>> Attachments: grant.html, grantRevoke.patch.Dec5, grantRevoke.stat.Dec5 >>> >>> Derby currently provides a very simple permissions scheme, which is >>> quite suitable for an embedded database system. End users of >>> embedded Derby do not see Derby directly; they talk to a application >>> that embeds Derby. So Derby left most of the access control work to >>> the application. Under this scheme, Derby limits access on a per >>> database or per system basis. A user can be granted full, read-only, >>> or no access. This is less suitable in a general purpose SQL server. >>> When end users or diverse applications can issue SQL commands >>> directly against the database, Derby must provide more precise >>> mechanisms to limit who can do what with the database. >>> I propose to enhance Derby by implementing a subset of grant/revoke >>> capabilities as specified by the SQL standard. I envision this work >>> to involve the following tasks, at least: >>> 1) Develop a specification of what capabilities I would like to add >>> to Derby. >>> 2) Provide a high level implementation scheme. >>> 3) Pursue a staged development plan, with support for DDL added to >>> Derby first. >>> 4) Add support for runtime checking of these privileges. >>> 5) Address migration and upgrade issues from previous releases and >>> from old scheme to newer database. >>> Since I think this is a large task, I would like to invite any >>> interested people to work with me on this large and important >>> enhancement to Derby. >> >> >>
