db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Orsini" <francois.ors...@gmail.com>
Subject Re: Grant -revoke (464) and future backwards compat
Date Tue, 28 Feb 2006 18:28:34 GMT
On 2/28/06, Øystein Grøvlen <Oystein.Grovlen@sun.com> wrote:
> 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?

This would impact Ease of Use  which has always been key to the Derby
charter. It is nice to get a choice but it can also be confusing -
Authentication is turned off by default as well and this came from a
ease of use requirement, mostly for embedded environments...

> 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?

Good point but if you have a way to enforce that feature to be used
then I would think it is - If a feature is supported and can be
enforced in some RDBMS then I would think it is compliant but that's
just IMHO.

> I also note that while easy-to-use and standards-based is covered by the
> Derby Charter, backward-compatibility is not.  ;-)
> --
> Øystein

View raw message