Oystein Grovlen - Sun Norway wrote:
> > I am not quite sure you understood what I meant. I do not suggest > that we should make SQL authorization default. What I was thinking of > was turning it on automatically when someone attempt to use it. If > one is only running existing applications one should not be affected > since they will not use GRANT/REVOKE. My itch is to make it easy to > start using Derby for people that based on experiences with other > database systems will assume that GRANT/REVOKE is available without > having configure the system. > I actually proposed doing this on the list on Jan 16... See this link: http://www.nabble.com/Re%3A-Grant-and-Revoke%2C-Part-I-...-DERBY-464...-p2410538.html As Francois pointed out, once you make the switch to sqlAuthorization mode, your "legacy" applications that are currently running could hit problems. There are sufficient number of differences between legacy and sqlAuthorization modes that, I contend, your applications would be affected. For example, in Derby Authorization mode, most users ("fullAccess" users) are like DBAs. They can access any database object without any explicit grant statements. The moment you switch the mode to sqlAuthorization, most users would become regular users without access to other objects. Someone has to issue grant statements to enable access to objects of other users. Wouldn't many currently running applications break after automatic switch? Note authorization is set a database level for all users and applications of that database. There are other differences between Derby Authorization model and SQL standard authorization mode too... Like triggers run as INVOKER in the former and as DEFINER in the later.. I will update functional spec to list differences between two authorization models. Since we both agree this can not be done for 10.2, may be we could revisit this issue after 10.2. Satheesh
