Øystein Grøvlen wrote:

> Satheesh Bandaram wrote:
>
>> Don't think keeping them undocumented is sufficient.. There are clear
>> specifications posted to JIRA and open source nature of Derby could
>> allow anyone to attempt to use the features. Even otherwise, GRANT
>> and REVOKE statements are well known and don't really need
>> documentation for many users. We would have to remove the underlying
>> code or disable parts of the functionality.
>
>
> I do not understand this.  Why do we need to actively prevent users
> from using undocumented features?

We don't... if the feature is implemented completely. At this point,
table privileges, routine privileges, schema privileges, database owner,
upgrade and metadata changes as described under DERBY-464 have been
implemented. What is not implemented include SQL standard authorization
for views, triggers and constraints, which follow definer authorization
model, rather than invoker. This means all authorization checks for
these three objects need to use the authorizationId of the person who
created them, not the authorizationId of the person using them. (As
specified in the SQL standard)

Now, if we release Derby with incomplete (or incorrect) authorization
model, don't we have to support this model in the future? Isn't this the
primary reason quoted for not releasing JDBC 4.0 at this point, since
the specs are not final and could change in incompatible way?

> In order to be able to release often, implementors of larger features
> need to be prepared for a release from trunk before their feature is
> completed.  One way to do this would be to provide an property for
> turning the functionality off.  What is a large feature in this
> context? I would say anything that takes more than 6 months to develop.

I agree. I did plan on completing all activities under DERBY-464 in time
for 10.2. When 10.2 date sliped to Oct, I planned to complete remaining
work by Oct. Now any change to pull this closer could put remaining work
at risk. It may be possible to remove some underlying code or disable
it, if absolutely required.

Satheesh

> -- 
> Øystein
>
>
>

Reply via email to