Satheesh Bandaram wrote:
Until these system privileges are ready, current proposal limits accesses that would cause forward compatibility issues. If sqlStandard mode allows unrestricted schema creation now, this would cause issues in the future where existing applications may need to change or we have to introduce another property like what is being done now. Current legacy authorization model is not compatible with standard model or what Derby might really want to support, but at the same time, we can't drop support for it because of existing applications. I believe Dan is try to ensure current proposal doesn't create any future compatibility issues, even if in the short term, Derby's new capabilities are restrictive.
My main concern here is usability. As long as the legacy mode is the default, it seems OK to enforce such restrictions in sqlStandard mode since it will probably not hit unexperienced users. Will legacy mode always be the default? Do we plan to switch to sqlStandard mode at some point in time?
Another important aspect of usability is that a product behaves in a familiar way. That is, the behavior is similar to similar products. I am a bit concerned if users will need to know about a specific property in order to be able to use GRANT/REVOKE. Also, can we really claim to be standards-compliant if one needs to set specific property in order to be able to use parts of the standard?
I also note that while easy-to-use and standards-based is covered by the Derby Charter, backward-compatibility is not. ;-)
-- Øystein
