Daniel John Debrunner wrote: >Do we really need such a property to be part of the public api, it just >makes Derby that little bit harder to use. > >Why not base the switching of the mode on the first successful execution >of a GRANT statement? > >I also dislike the two modes, and am stil looking at ways to avoid it. > > It is a worthy cause... if you can find an appropriate way to achieve this. We did talk about switching the mode during first execution of a GRANT statement and was rejected before. See this thread and several others:
http://www.nabble.com/Re%3A-Grant-and-Revoke%2C-Part-I-...-DERBY-464...-p2410538.html This is because of several reasons... 1. We all agreed switching from Derby authorization to SQL authorizaton mode would be visible to applications or users and could break existing applications or usages. Especially switching automatically could and would cause confusion. 2. Can any user switch the mode triggered internally or only database owner's GRANT statement would switch the mode? How do you account for "accidental" switching of the mode when their real "intent" is not to switch? Derby doesn't support switching mode from SQL authorization back to Derby authorization mode. 3. Another issue is lack of system privileges and how it impacts object privileges at the moment. There are several severe restrictions imposed on SQL authorization mode and users adopting to SQL authorization should be sufficiently be warned (or even prevented a little) until system privileges are done. Automatic switching might get more users into something they may not want. 4. Many applications are likely to see differences between Derby authorization and SQL authorization anyway. Why hide it? 5. Getting this design past Kathey would not be worth the effort :) Seriously, 'Existing Application Impact' flags everywhere! I had originally suggested keeping a flag at database create time with current default being Derby authorization for now and switching to SQL authorization mode in a phased manor as system privileges are later added. This scheme would have eventually allowed us to drop support for creating new databases in Derby authorization mode less painfully, I think. But this current scheme exposes public properties and removing them might be harder, while it does allow easier switching in the short term. Satheesh
