Re: [gnome-db] Oracle, Table Names and Progress

On Sat, 2003-02-08 at 22:22, Steve Fosdick wrote:
> On 08 Feb 2003 18:24:44 +0100
> Rodrigo Moya <rodrigo gnome-db org> wrote:
> > On Sat, 2003-02-08 at 14:30, Steve Fosdick wrote:
> > > > -> for every object, a list of flags describing what the user
> > > > which is   connected can do on the objects (select, ...)
> > > 
> > > Have you thought what flags?  We want to be sure to cover all the
> > > bases. The ones that spring to mind are: SELECT, UPDATE, INSERT,
> > > 
> > I guess this would be better done via the GRANT/REVOKE API we have
> > talked about (
> > Another to call to retrive the permissions for any object should be
> > added, apart from the GRANT/REVOKE calls in each provider.
> I looked at the buglist entry you refer to.
> Does anyone know of any databases with permission checking any more
> precise than table-level?
I don't recall any, although my memory isn't very good :-)

>   If not then we should be able to implement a
> get_permissions call fairly easily which takes the name of the object -
> if the underlying database only does permission checking at user/schema
> level it can just ignore the name of the object and return the same
> permissions for everything.
yeah, seems a good idea.

> We would also need a way to discover whether the current user is able to
> create new objects.  Oracle checks the permission separately for each
> type of object, TABLE, VIEW, SYNONYM etc, so we would need to specify
> the object type in that call or have the call return a list or bitmap of
> what the user can create.  Does anyone know of a database that requires
> us to be more specific than that?
yes, we should have room for the most features, so I guess we should
have an enum:

typedef enum {
} GdaPermission;

which contains the most fine-grained detail we need.

> Having the application check for permission using the extra call would
> obviously be extra work for the application.  It may save execution time
> though if the application doesn't routinely check the permission of
> every table but only checks before letting the user do something that
> requires the permission concerned.  If the application is going to step
> through every table though and fetch this information it would probably
> be faster to have it returned by the GDA_CONNECTION_SCHEMA_TABLES call
> as originally proposed.
yes, we could add an extra field (an integer containing the enum's OR'ed
values) for each schema. But, apart from that, the get_permission call
would be needed.

This weekend, which I hope to have some time, I'll start the basic
implementation of this.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]